0.8 release plans

[Martin Pool]

I'd like to sketch a map for an 0.8 release in the next few weeks.

Ubuntu's Dapper release will ship with the version of bzr from March.
Robert, James and I would like to make sure that some pending
improvements on top of 0.7 can get into that release, implying an 0.8
release in early March.  (This is not going too far out of our way,
since we want to get towards 4-6 week releases anyhow.)  From this point
on bzr is going to be more extensively used by Ubuntu and Canonical
developers and so we would like data and code that depends on this
release to be supported for a fair while (6-12 months).  API stability
was previously discussed here and I think we have a good understanding
of what can be done as far as deprecation and documentation -- it's not
totally black and white.

There is some scope for putting bugfixes into the dapper-updates channel
if there are problems, but they really should be bugfixes not new
features.

Robert pointed out this morning that Baz suffered a bit from changing
the default format, which in a distributed system tends to force
everyone to upgrade.  To avoid that Robert and I and Canonical would
like the format used by 0.8 to remain the default format for future
releases, say through the following 12 months.  That doesn't mean there
can't be new formats, or that they can't be recommended for particular
situations.  It's hard to predict what developments we will see in the
future, but this is the goal.

These imply trying to integrate the features that majorly affect storage
format or API before this release, and in particular those that enable
later development.

The major features still to land for this then are

 * bzrdir refactoring (if more remains to be done?) - this allows 
   having directories which contain either branch, repo, or working
   directory data, or any combination.  This enables checkouts, 
   shared storage, etc. 

 * tagging

 * nested tree support (at least in data formats)

 * changes to ignore handling

 * VersionedFile 

 * new locking that's better across non-local transports

 * working directory last-revision marker

 * John's format-7 branch(?)

 * (what else? please reply)

Other things might be good to land as well; please reply and add them.
TreeTransform perhaps doesn't relate to data stability but looks like a
nice cleanup, for example.  I would like to hook up tests for PyCurl and
get that in, and to change inventory and revision to Rio format to
relax the ElementTree dependency.

This sounds like a lot (and is a lot), but in many cases there are
already good branches:

The timeline should be approximately:

   1 Mar    make 0.8rc1 release candidate, start 0.8-fixes branch
  10 Mar    0.8 final?

Robert and I will be making a push to get the existing code on this
updated (if necessary), reviewed and integrated.  (Which is kind of bad
timing for me because I'm trying to move to Sydney at the same time, but
we'll manage.)

What do you think, sirs?

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/3dbf1db6/attachment.pgp