Web lists-archives.com

Re: changelog practice, unfinalised vs UNRELEASED vs ~version




On Mon, Feb 20, 2017 at 08:05:02PM +0000, Ian Jackson wrote:
> Guido Günther writes ("Re: changelog practice, unfinalised vs UNRELEASED vs ~version"):
> > On Sun, Feb 12, 2017 at 12:48:35PM +0000, Ian Jackson wrote:
> > > We do not seem to have a coherent approach to how to handle
> > > debian/changelog in trees (eg, vcs branches) which are not yet ready
> > > for upload.
> > > 
> > > See below two examples of things done differently.
> > > The questions are:
> > > 
> > > Q1. Should the suite in the changelog entry be UNRELEASED,
> > >     or the suite at which the vcs branch is targeted ?
> > 
> > DEP14 allows for branching schemes that have the desired suite included
> > like debian/sid, debian/experimental, debian/stretch so the information
> > is included in the VCS and UNRELEASED only indicates the "not finished
> > yet" part.
> 
> I think the asnwer to this is the same as that I gave to Wookey who
> mentioned a workflow involving vcs tags.
> 
>       I think we should agree, as a project on some conventions about
>   what debian/changelog would mean if you find it in some vcs branch
>   (or, for that matter, a tarball or whatever someone sends you).  I
>   definitely don't think vcs tags are the right answer.  They are not
>   always transported with the revision and vcs-unaware tools cannot
>   see them at all.
> 
> This is (almost) as true for branches as it is for tags.

It's fine to send tarballs around but it should (hopefully) rather be
the exception to "git format-patch" or a public VCS repo. So it's IMHO
rather the later case we should optimize for.

> > > Q3. Should the version number be the intended next version number,
> > >     or should it be decorated with ~something ?  If it should
> > >     be decorated, what should it be decorated with ?
> > 
> > gbp dch adds a ~<N>.gbp<M> by default. N being the snapshot number (the
> > nth time you ran dbp dch since the last release) and <M> being the first
> > digits of the sha1. This allows for
> > 
> >    * easy identification of snapshot builds
> >    * increasing version numbers useful for e.g. CI builds.
> >    * a version number that is smaller than the final release number
> >      so systems having snapshot builds can be easily upgraded to
> >      release versions
> >    * a mapping back to the git commit until when the changelog was
> >      filled.
> 
> This is all fine.  What it lacks is a way to stop you accidentally
> uploading an unfinished ~gbp snapshot, based on the version number.
> I was proposing ~UNRELEASED.  Obviously that could be
> ~UNRELEASED<N>.<M> (with N and M from your notation).

But if the suite is UNRELEASED you don't have that issue or am I missing
something?
Cheers,
 -- Guido