On Sun, Mar 29, 2009 at 06:20:48PM +0100, Adam D. Barratt wrote:
> Hi,
>
> On Sun, 2009-03-29 at 16:55 +1030, Ron wrote:
> > wacom-tools$ dch -i
> > dch: fatal error at line 1043:
> > Error parsing version number: 0.8.1.6-1+
>
> What version number would you expect dch to generate in this case?
Hmm, that's a good question :) In this case I was really just being
too lazy to type -v $new_upstream_version, and didn't really care
what version it gave me, I just wanted a new changelog stanza and
was expecting to edit version and distribution manually ... so just
not failing would have sufficed.
But I guess let's look at how it might have worked if I was doing
this 'properly':
0.8.1.6-1 was source uploaded to unstable
0.8.1.6-1+ was the same source uploaded to experimental, but built
with newer versions of the build deps (xorg from exp).
so if there had been another debian revision of that version, the
next two entries in the changelog would likely have been:
0.8.1.6-2, followed by 0.8.1.6-2+
> Where the version ends in ~, we essentially remove the character,
> increment the version and then reappend the ~. We could apply the same
> procedure in this case, so "dch -i" would give you 0.8.1.6-2+.
Treating these all the same would probably be the least surprising
thing to do. I do wonder if just stripping them off and leaving
them off would not be a simpler and more often correct solution
(since ~, + and such seem usually used for in-between versions).
The convention above was discussed on #d-d before I used it, but
I don't know how representative it really is of what others have
done. If this were a day zero decision, I'd probably say just
strip them off -- if changing that for ~ now would upset people,
then I'd probably say treat + like that too (unless someone can
think of a really good reason to treat them differently). Hmm,
actually should ~ be stripped off and the version _not_ incremented
given the way we sort ~ ... ?
Anyhow, I won't complain about choosing either method -- I usually
try to avoid ever needing a -2 release where possible, so I already
expect to have to hand edit the release version most times. :)
So long as I get the date stamp and boilerplate for a new stanza
it's done the work I wanted it to.
Cheers,
Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
