File format roadmap needed (was Re: [MERGE] New 'development' format.)

[Robert Collins]

On Thu, 2008-01-03 at 11:25 +1000, Ian Clatworthy wrote:
> Robert Collins wrote:
> 
> > I don't want the overhead of three experimental versions, subtree and
> > rich-roots can be pulled between (as long as a subtree hasn't been
> > used), and anyhow we should be looking at making rich-roots a default
> > soon.
> 
> Now that 1.0 has shipped, I think we ought to be publishing some
> policies w.r.t. file formats and a roadmap reflecting those. I think
> this patch is a good start but more is needed, particularly on the
> planning front IMO.

Is that bb:approve I hear ? :)

> While *I* think we've generally done a good job on incrementally
> changing formats at the 'right' times, we continue to get flak about how
> often we do it (with the implication being that Bazaar is not yet ready
> for production use), e.g.
> http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/:
> 
> "Also, Bazaar has a history of changing the repository format. Again,
> now that Bazaar has hit 1.0, hopefully they won’t be doing this very
> often, any more."

Meh. Show me an open source project that has stopped changing. hg has
had 3? 4? revisions. git has had several that they haven't announced
(because they presume everyone runs bleeding edge?). See for example the
addition of subtree support to git. CVS and SVN too have had revisions
post 1.0.

Someone is advertising falsely about the stability in a VCS and we're
copping design flak about that. I think we should argue right back.
Technically we're doing great IMO.

> So, we either need to:
> 
> * do it less often and to a roadmap where (post 1.0) users are excited,
>   not annoyed, about each and every upgrade
>
> * make upgrades so painless that users hardly notice.

I don't think we need to change what we're doing.

> Being able to change formats easily is almost a strength of ours. I say
> "almost" because we're not yet at the point where 'upgrade' can be given
> a shared repository and it will magically do each branch using it. Is
> that enough to make upgrades painless? Possibly not. We might need a
> tool that scans a tree looking for all repositories as well.

Branch and Repository formats are decoupled; you don't need to upgrade
the branches when you upgrade the repository. Sure it might be nice to
add a recursive option to upgrade - file a bug.

> One possible policy is "the default file format will not change for N
> months" where N is 3, 6 or 12 say. 12 is a good goal but not sensible in
> 2008.

I don't think is a sensible policy; it requires predicting the future.

> How would that list change if we went with a 3 month window instead?

How about changing the default when we have a default that is better and
we think is worth whatever nuisance value the upgrade will cause? E.g.
to assess each change on it's own merits.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080103/f377d9b2/attachment.pgp