bzr version numbers

[Martin Pool]

> 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.

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.

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?

-- 
Martin <http://launchpad.net/~mbp/>