bzr version numbers
russel.winder at concertant.com
Mon Dec 1 20:18:42 GMT 2008
On Mon, 2008-12-01 at 12:50 -0600, John Arbash Meinel wrote:
> > 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 :).
(One could go on for potentially many years like this, but is it worth
> 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 think that makes it an agreed thing, names are only useful where the
rate of change is relatively low.
Also the time required to choose the names will detract for the
important work of evolving Bazaar.
> 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
As a user, I have to reiterate that I haven't a clue how to deal with
all these -- but this has already been aired on the email list.
The real problem is, of course, deprecation. For example (sorry Jelmer,
Format <RepositoryFormatKnit3> for http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
As a user, I have no control, just vast irritation as I get messages
about which I can do nothing.
> 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.)
There is an alternative: Format 1, Format 2, Format 3, etc. The
integers make a very good sequence numbering that carries little or no
baggage. An alternative would be Knit, Dirstate, Pack, Stack, BTree,
but this opens up the door to silly sniping: why BTree when
RedBlackTree is quicker -- this is a fatuous comment on my part of
course as in this case BTrees are likely the best data structure, but I
think you'll get what I mean.
> > 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.
OK, this is the one that got me to do a response, the above is just
(hopefully humorous) intro.
Deprecations should not be determined by time unless there is a rigid
relationship between time and releases. Deprecations should be
determined by formal releases. So three releases between announcement
and removal for example. Any temporal relationship is generally purely
> 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".
Announce deprecation, reinforce deprecation, remove -- so not in next,
it's too soon.
As we know Sun have a very poor, even bizarre record of deprecation with
the JDK -- nothing ever actually gets removed, and some deprecated
things get un-deprecated!
Fortunately is was a sane decision to undeprecate the things they did.
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081201/365395af/attachment.pgp
More information about the bazaar