bzr version numbers

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...
> 
> On the other hand it is a serial number and so people know where they
> are in the release sequence.
> 
> The Ubuntu naming scheme of 8.10 really does nothing useful for me since
> it is basically meaningless.  2008-10 means a lot more since I
> understand ISO 8601.  I guess though Ubuntu will not be around in 3000,
> so there isn't actually a problem.   Intrepid Ibex is equally
> meaningless of course but does allow for some humour -- at least for 8.5
> more years at which point it all falls apart.

Isn't that 9 years, since you can do something with "AArdvark". I don't
know of any BB words :).

>  
>> 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.
> 
> Or it becomes a simple vehicle for fatuous humour -- or sometimes satire
> (intended or not), see the releases of Sound Juicer.
> 

I like the idea of code names, but I feel that releasing every month is
going to turn them into as much jumble as everything else. I think a
6-month cycle is about the minimum that you would think about long
enough to have any number or name stick.

I have to agree that I tend to only remember semi-major releases when a
new format came out.

0.8.2 was the beginning of knits
0.15 was dirstate
0.92 beginning of packs
1.6 stacking
1.9 btree

In a way, we could argue for a deeper numbering scheme, and only bump
the minor when we have a new disk format. (either when it is released,
or when it is made the default.)


>> 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.
> 
> Not sure about deprecations as they are fundamentally sequence number
> oriented. Formats can surely have an orthogonal naming scheme, I don't
> see why the version number of introduction has to be encoded in the
> format name.  Or am I missing something obvious to the Bazaar
> development team?

Well, the idea with deprecations is that they should be preserved for X
months from when the deprecation started. We could thus do it as a date,
but it should really be the date it gets merged to PQM or released as a
package. Which means some sort of (possibly automatic) munging needs to
be done.

Right now, you tend to do $next_release, but when it slips, you have to
go around and keep updating that. So we *could* just have an explicit
DEPRECATED_IN_NEXT string that part of the PQM merge process would then
overwrite that string with whatever is actually going to be "next".

>  
>> Let's not bikeshed this; everyone has opinions from random projects.
>> How about making the January release 9.1?
> 
> In the end it is your choice as project manager.  I would just release
> 1.11 and avoid unnecessary fashionism.
>  

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk0MfoACgkQJdeBCYSNAAOndgCgz/KQ3QAO50M5lUa6i2ffcxR6
zZkAoMgN9Zua4PLEBvRf9FKDTlAKnlVY
=3eLS
-----END PGP SIGNATURE-----