[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: changelog practice, unfinalised vs UNRELEASED vs ~version

Wookey writes ("Re: changelog practice, unfinalised vs UNRELEASED vs ~version"):
> I'd be happier if I didn't have to deal with 'UNRELEASED' at all
> unless I actually wanted to, so I'm not at all keen on your suggestion
> of making it mandatory.

Well, tools can be configured, too.  If my UNRELEASED version proposal
is adopted, we could easily let you have a DEB_ENABLE_FOOTGUN variable
that will let you become confused about what binaries and sources are
what, by reusing version numbers from ad-hoc test builds.

> 1. I really dislike dch's enthusiasm for putting in 'UNRELEASED'. It
> gives me nothing I wanted, and just provides the opportunity to really
> do a final, clean, tested, build, only to find on upload that it's
> still marked 'UNRELASED', and I have to do the build, test, upload
> step again - for big packages that is a huge pain and happens way too
> often. I really resent that there is no way to do dch -i;dch -r in one
> go - the separation of these is just makework for me. 

Does that mean that if you tested ~UNRELEASED, and it passed all your
tests, you would be unhappy to strip the ~UNRELEASED from the version
and upload it ?

I often do that.  My tools make it very hard for me to mess this up by
uploading anything whose source tree (besides the changelog and
therefore besides the version number) differs to what I tested.

(Of course in principle there might be situations where version
X~UNRELEASED would be treated differently to X.  If that's likely to
be going on then I would have to, regrettably, use the actual
for-release version number for your ad-hoc tests.)

> > Proposal:
> > 
> >  * Tools which add/edit changelog change items should insist that the
> >    changelog is unfinalised and contains ~UNRELEASED in its version.
> I really don't want this to be _required_. Dicking with the version is
> better than dicking with the suite, but I really would prefer it if
> the tools did neither, or could simply be asked to.
> I realise that I'm pushing uphill somewhat here and no-one much cares
> about people who still don't use git if they don't have to. But the
> UNRELEASED/'dch -r' thing pisses me off on a daily basis, and this
> seemed like the time to point out that some of us don't find it all
> helpful. From that POV, moving it from suite to version would
> definitely be less annoying.

Well, I guess you'd be satisfied with an option to disable this

But: it seems that intend to make commits whose debian/changelog has a
trailer line, a real suite, and a real version, but where the commit
does not contain all the changes ?  I think that's poor practice.
These commits are a liability.  If you push such a commit, and then
later make more changes and do the upload, but forget to to push, a
subsequent upload made from the vcs might lack your changes.

Of course if you really insist you can do this, and probably if the
commits are buried in the history so that no-one every sees them
except when doing archaeology, then there is little chance of your
metadata misleading anyone but you into a mistake.

I don't know how you avoid mistakes.  Perhaps you're just very


Reply to: