Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Guido Günther writes ("Re: changelog practice, unfinalised vs UNRELEASED vs ~version"):
> On Mon, Feb 20, 2017 at 08:05:02PM +0000, Ian Jackson wrote:
> > 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.
Even if a VCS is used, the branch name may fail to indicate the suite.
"refs/heads/tmp.for-guido" doesn't say "I mean this for experimental".
(And of course not all VCSs do branches the same way.)
It is the very contents of the tree (ie, its actual source code
contents) that mean it is suitable for a particular suite. The
metadata that indicates this to the tools should be in-tree too.
> > > > 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. [...]
> >
> > 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?
See above for why the suite needs to name the real suite. We could
decorate the suite instead, but that does not have any effect on
generated binaries. As I say, the unfinalised version of the package
should generate binaries with non-release versions.
Ian.
Reply to: