bzr version numbers

[Matt Nordhoff]

Martin Pool wrote:
>> On Mon, Dec 1, 2008 at 8:07 AM, Robert Collins
>> <robertc at robertcollins.net> wrote:
>>> I wonder if it would be good to start using dates as part of our
>>> versions? I just commented on a bug reported using 1.5, and I couldn't
>>> (offhand) remember when it was released...
> 
> But that would constrain us to actually releasing them in particular
> months. ;-)  (A smiley there because keeping the regular rhythm seems
> almost always better than any transient reason for delaying.  In the
> worst case we can always bump the number.)
> 
> Perhaps most importantly, doing this would be that we couldn't use
> round numbers for big transitions, like 2.0.  However, for a project
> with features coming in as experimental and with regular releases it's
> a bit hard to ever make these big bangs: there's no single moment
> where it's released to the public, I don't think it makes sense to
> save up features for the sake of a big release, like you might in
> proprietary software.
> 
> You already know 1.5 was roughly 10-5=5 months ago (in fact, 6½).  I'm
> not sure if mapping to a precise date is a really compelling case, and
> I realize you weren't saying it is.
> 
> We're unlikely to do major releases more than once a month, though we
> might do point releases.  There may be cases where we've released in
> the past on eg the 1st and 29th.
> 
> Now, at the end of the year and having just gone in to a double-digit
> minor version (which causes some little confusion about 1.10 vs 1.2),
> could be a good time to change.
> 
> Going 1.7, 1.8, 1.9 feels a bit like it's creeping along, whereas
> making them date-based makes a virtual of reliability.

Given bzr's development process, date-based version numbers like
Ubuntu's make sense. My biggest objection is that most software I use
has a major version number of 0 or 1, and hardly any is above 3, so
jumping from 1.9 to 8.12 or 9.01 would feel very strange to me,
especially given bzr's age. I think Marius Kruger's idea about making
them relative to the "epoch of bzr" is interesting.

> A couple of orthogonal points:
> 
> I'd like to add code names so they have a bit more colour, and it's
> more memorable what happened in them.

What kind of codenames? If you mean arbitrary ones like Ubuntu uses, I'm
against that. I've got a decent handle on Ubuntu, but bzr releases way
too frequently for me to be able to remember them.

Also, since format names include the version number, I find the numbers
themselves pretty memorable. (Or at least 0.15, 0.92, 1.6 and 1.9. I
can't remember a thing about the others. :-P )

> It's annoying that deprecations and format names need the version
> coded into the patch when they start, even though it's hard to tell
> what precise release they'll land in.  I guess we could change to
> "deprecated after $previous_release" and then it will at least be
> true, though maybe too loose; or we could search and replace for some
> token.
> 
> Let's not bikeshed this; everyone has opinions from random projects.
> How about making the January release 9.1?

Right. I'll try not to bikeshed it too much. I'll be fine with whatever
decision you make, as long as it's shorter than 9.1.20090101 "Lively
Lemon". ;-)

Wait! What about something like TeX? 3.1, 3.14, 3.141, 3.1415, etc. :-D
*duck*
--