0.8 release plans

[Jan Hudec]

On Wed, Feb 08, 2006 at 13:12:24 +1100, Martin Pool wrote:
> 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

I just wrote about this a bit in reply to the nested tree support
proposal, but it belongs here, perhaps in more general way:

  * generic scheme for versioned metadata

    We will need versioned metadata for:
      + nested tree support (URLs to search the child trees at)
      + ignore handling
      - plus refactoring of the executable flag handling
      (that's for now, but in future we want to add:)
      + line-ending conversion
      + charset conversion
      + keyword expansion
      + alternate diff and other goodies like that, some day
    All this data is inventory-entry-related. Also except for ignore
    handling and executable flag handling, which will change from
    incompatible current implementation, all the others are in fact
    backward compatible in that:
     - Branches that don't use them are not affected at all.
     - Client that can't handle them can still work with a branch that
       uses them, except for the particular functionality they bring.
       It has to be able to preserve them though, so the basic support
       must get in.

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

Ad TreeTransform -- it is one part that has to deal with the versioned
metadata thing. So it should be decided whether the versioned metadata
will land before or after TreeTransforms.

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

It's not a lot of time... It will take a lot of pushing.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- 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/bea635da/attachment.pgp