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