On 2017-02-14 23:01 +0000, Ian Jackson wrote:
> 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.
I have a 'current' version, which is the one that will be uploaded
when it's deemed good enough to upload. I don't find that confusing.
> > 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 ?
Well. If I changed the version I'd still have to do a rebuild to get a
matching .changes and .dsc. (perhaps there is a shortcut to this?). So
it's just the same problem as having UNRELEASED in the changelog,
except that it's much easier to notice, becuase it's right there in
the version in the filename.
> (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.)
Indeed. I like to test exactly the thing I'm going to upload, not
something with a different suite or version number.
> > > 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
> behaviour.
I would. And I'm very grateful to whoever it was in this thread that
pointed out that one currently exists.
> 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 ?
You are still talking about commits, which implies a VCS. I have a
plain directory containing 'the package' (quilt format so my changes
are reasonably clear). When it's finished I upload it. Debian's
archive stores the definitive 'tagged' version for me.
> 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.
All N/A so far as I can see. The version in front of me is the version
I'm working on. It has a version number. Changes are added to the
changelog until all the changes are done (as a changelog is intended
to be used). Then it is uploaded. I am a very simple individual :-)
> I don't know how you avoid mistakes. Perhaps you're just very
> careful.
I avoid making mistakes by not using a vcs I don't really
understand. :-) Each version of the package lives in a directory. I
only work on 'latest'. uscan and uupdate manage the creation of new
directories containing new versions, from new upstream releases. dch
manages changelog editing without screwing up the format. quilt
manages the creation of discrete changes. I take some care not to
confuse quilt (which is very easily done, but I understand it so can
fix things when I mess it up).
None of this is helped by the 'UNRELEASED' mechanism.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Attachment:
signature.asc
Description: Digital signature