bzr version numbers

[Martin Pool]

On  4 Dec 2008, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Vincent Ladeuil writes:
> 
>  > Given this three paragraphs, how about bumping the major version
>  > number when we decide to make a given format the default one ?
> 
> >From what I know of the bzr process (a year lurking/sometimes
> contributing on this list, basically) that sounds reasonable.
> 
>  > >From a stratospheric point of view, the most important changes,
>  > as a bzr user were the introduction of:
>  > 
>  > - dirstate,
>  > - packs,
>  > - the forthcoming chk-inventory 
>  > 
>  > If you think about it, 1.0 was released when packs-0.92 *and*
>  > some other parts of bzr were stable enough. 'dirstate' may have
>  > been a stepping stone too, but wasn't.
> 
> Yes, I would agree with that assessement (again, as an outsider).

Ok, so we could do this pretty well from here, and there's one obvious
milestone for a future bump to 2.0.  We keep going with 1.11, etc
releases, approximately on calendar months.  As the brisbane-core branch
stabilizes and merges in, it will become available as a
development format in our releases, to get more exposure and so that we
make sure it's consistent with everything else we merge.  

After some testing there, it'll be a stable but non-default format, but
called e.g. 1.14.  After further and wider testing, we can make it the
default and at that point call it 2.0.

So then the major version bump would occur at the time when the
default-created format comes out, and also the time at which we most
want to communicate the changes which are fully tested.

It might be slightly confusing that the default format in 2.0 is
actually called e.g. 1.14.  We could just go with that, saying it's
because it's compatible with 1.14 and later.  Or we could land it in
1.14, calling it 2.0 but noting it's supported from 1.14 onwards.  Or we
could give it some arbitrary name, but that has not worked well in the
past.

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