bzr version numbers

[Martin Pool]

On Tue, Dec 2, 2008 at 7:18 AM, Russel Winder
<russel.winder at concertant.com> wrote:

>> 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 think they should be primarily known by numbers, unlike Ubuntu.  If
the RM or a developer cares to stick a nickname on it, fine.

> The real problem is, of course, deprecation.  For example (sorry Jelmer,
> but...):
>
> 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.

Bug Jelmer in public. :-)

It's a tough tradeoff though - pulling from a knit repository is going
to be substantially slower and it seems wrong to let people just
suffer that with no indication why.  Perhaps the message could be
better.

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

We learned our lesson here.  We now use sequential numbers for the
classes <BzrBranchFormat6>, and the top-level user interface is to say
--1.6 or --1.9, making it obvious which version can read it.  (Using
names like 'dirstate' or 'knit' has the problem that there's no
apparent ordering, and that they're named by the technology used as
one part of the format.)  There are still infelicities here in that
it's a bit hard to for the user to understand which option gives you
eg Branch6, but there are bugs discussing how to fix them, and they
will get done.

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

The relationship is close enough that I don't know if it's worth
drawing the distinction.  Does it make a difference to users if we say
'will be kept for six approximately-monthly releases', or 'will be
kept until the next release after six months have passed'?

In any case it is not a precise science: for APIs, it's hard to define
in Python just what is public or not (unilke Java), and for both
formats and APIs we're likely to leave it supported until there's a
positive reason to remove it.

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