Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Sean Whitton writes ("Re: changelog practice, unfinalised vs UNRELEASED vs ~version"):
> On Sun, Feb 12, 2017 at 12:48:35PM +0000, Ian Jackson wrote:
> > Q1. Should the suite in the changelog entry be UNRELEASED,
> > or the suite at which the vcs branch is targeted ?
> > [...]
> > Q1: Replacing the suite with "UNRELEASED" means that it is not
> > possible to distinguish a branch intended for experimental from one
> > intended for sid, other than by branch name (and of course branch
> > names are often used for other purposes). I think this is very
> > undesirable. AFAICT only reason to use UNRELEASED is to prevent
> > accidental upload, but maybe we can do that some other way.
>
> Why do you think this is "very" undesirable? At worst, you have to ask
> the person who committed to the branch what their intention was, and
> you're probably talking to them anyway.
No, at worst you upload to unstable something that ought to have gone
to experimental, because the tooling failed to notice your mistake.
If you had been able to note somehow in the relevant vcs branch that
it was intended for experimental, you have a much better chance of
having done so - and the tools would then be able to catch it.
> > Q2. Should the changelog entry be finalised ? That is, should it
> > have an uploader name and date ?
>
> Just a terminological point:
>
> I use "finalised" to mean "suite is not UNRELEASED and timestamp is not
> behind the last change" -- i.e. `dch -r` has been run and the result
> committed.
>
> I suspect I'm not alone in using "finalised" to refer to this, given the
> behaviour of `dch`. It is only the Emacs changelog mode which leaves no
> name and e-mail.
There's two meanings of "finalised" then.
One is "contains name, email address, and date of purported decision
to upload". (Let's call that "with trailer" from now on.)
The other meaning is "has been updated to reflect decision to upload,
including recording name and email of the person making that decison
and the time they did so". (Let's call that "upload decided".)
I think that recording a false or dummy set of information about a
purported upload decision is a silly way of recording the fact that
the upload decision has not, in fact, been taken.
I think tools and people only do it this way because some other tools
have been grumpy about changelogs without trailers. This is also
silly, since they're all our tools and we could just fix them.
> > 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 ?
> > [...]
> > Q3. If the version number is not decorated, then binaries (or even
> > source packages!) built for testing (or for other reasons other than
> > upload) are not always distinguishable from intended-for-release
> > builds. IMO this is very undesirable.
>
> If we use dgit for all our uploads then this doesn't really matter :)
That's not true. I would like to know, for example, whether the
version of sysvinit I have running on my laptop is the version I
finally uploaded to sid, or some pre-release which might not be
identical to sid's.
Ian.
Reply to: