bzr version numbers

[Colin D Bennett]

On Mon, 1 Dec 2008 13:30:16 +1100
"Martin Pool" <mbp at canonical.com> 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...

I'm not completely against date-based version numbers, but as often as
you need to look this up, you could just open up the NEWS file and grep
for it, as another responder suggested.

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

I certainly don't find 1.10 vs 1.2 confusing:
   "one point ten"  versus  "one point two"
seems straightforward.

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

IMHO it doesn't matter if the numbers are based on dates or simply a
monotonically increasing counter; as long as they are increasing, I'll
be just as happy.

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

Please, no.  At least, not like Ubuntu.  I like Ubuntu a lot, but I
absolutely loathe the code names.  They're funny and cool for about 30
seconds.  Then one person says, "I have Hoary Hunter", and another says
"I have Intrepid Ibex", and another says, "I have 8.04" -- do you know
what order these were released in?

Numbers are simple, concise, and they intuitively and instantly
indicate ordering.

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

I really don't care too much, but it just seems like date-based version
numbers are the latest fad to me.  Ultimately, as long as we don't get
hooked on silly "code names" for the versions, I'm OK with either
choice.

We just need to pick a path and stick to it, however, since it is
*really* confusing for users when programs skip version numbers.  For
instance, some of the most obnoxious changes I have seen:

* "Java 1.4" -> "Java 1.5" -> "Java 6"

* "Unreal Tournament 2004" -> "Unreal Tournament 3"
  (interesting example of switching *away* from a date-based version
  scheme)

I know there are more examples of weird version numbering scheme
changes, but I can't think of any off the top of my head.

Regards,
Colin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081202/0c027681/attachment.pgp