asterisk 1.2.0-0beta1

[Mark Purcell]

Tzafrir,

Thanks for the commit work.  I guess we will go through some growing pains as 
we move to more shared working.

Note the zaptel-1.2.0-beta still is not really in a releasable/ working shape 
yet either.

On Sunday 02 October 2005 12:50, Tzafrir Cohen wrote:
> On Sun, Oct 02, 2005 at 09:47:28AM +0200, Jose Carlos Garcia Sogo wrote:
> > El dom, 02-10-2005 a las 03:21 +0300, Tzafrir Cohen escribió:
> > > I just commited to the svn initial Asterisk 1.2 debian/ dir. It
> > > generally seems to work, but still needs some work.
> >
> >   OK, only some problems with this commit
> >    1. If it is targeted to experimental, it should have gone to
> > branches/scud, instead of trunk, to allow newer uploads to unstable
>
> OK. Somehow that point have escaped me when reading the README.

The README for pkg-voip does state that experimental development will be made 
in trunk/ and that if an new unstable package is needed it can occur through 
copying from tag/. I have come across a similar issue with pkg-kde-extras, 
where I copied the README from pkg-voip.

Happy to work with either system, in the asterisk case a branch makes sense as 
there appears to be potential differences between the packaging for the two?
Where is the branches/scud option documented, if anywhere?

> >   Which means that when we want to upload released 1.2.0, we will have
> > to use another trick or mak epoch 2: For example, something as easy as
> > 1:1.2.0.beta1.dfsg-1 will work (as final will be 1:1.2.0.dfsg-1 and d >
> > b) Anyway, dpkg --compare-versions is your friend in this situations.
>
> I didn't like it either. But I saw it used in the libpri package. What
> would you suggest? Also considering that the original tarball will
> differ from beta1 to final.

The commit/ and upload of libpri was a mistake on my behalf :-( as has been 
pointed out they aren't lower :-(  We can finesse the libpri & zaptel 
numbering mistake when the release version 1.2.0 is uploaded to unstable as 
there is no checking that packages uploaded to unstable > experimental.

I have just committed the asterisk changelog to trunk) with the 
1:1.2.0.beta1.dfsg-1 numbering as that seems best and most sensible.

The .orig.tar.gz will actually be two different uploads as 
1:1.2.0.beta1.dfsg-1 & 1:1.2.0.dfsg-1 will be considered as two different 
upstream packages and each will require it's own .orig.tar.gz.

> >   I was going to fix this a bit, but first I need to know if this
> > release is intended for experimental or not.

Yes this should go into experimental. As a rule of thumb I like to keep cvs 
and non-released versions to experimental provided there are relatively 
mature released versions in unstable.

> Very. I would have given it more polishing if I had not suspected this
> would mean yet another week of delay.

This is what svn is for, so that we can all do a bit at a time. At least we 
have a 1.2.0.beta commit we can start working on together. Once we are happy 
then we can tag/ release. So please polish away!!

Mark