requirements and roadmap for 1.0

[Jari Aalto]

"Martin Pool" <mbp at sourcefrog.net> writes:

> Commitment: once we call it 1.0, we take on an increased level of
> commitment to consistency from one release to the next, in data
> formats, command lines and apis.  I think we are already generally at
> a good level: we normally bring in formats before they become
> defaults, we have reasonable warnings about minimum versions and
> deprecations.  I think this requires a somewhat increased level of
> caution but it would not be a burden on future development.  If we
> were planning to have a waterfall date at which all data becomes
> incompatible perhaps we would defer 1.0 until afterwards, but I think
> that is not really needed or feasible given our existing users.

Just an observation from a user point of view. Following DVCS
programs have releases:

    - Git is at version 1.5.2.2
    - Hg is at version 0.9.x (*.4 I think)
    - Darcs is at 1.0.9
    - Monotone is at 0.35

The version numbering notation that seems to dominate most is X.Y.Z,
which bzr could also adopt. What those parts actually mean is a
separate discussion. On top of my head:

    X = really big changes (incompatibless, conversions, radical new 
        functionality.

        - Is this even likely for bzr which advances gradually 
          feature by feature and then there is "bzr upgrade"?

    Y = Feature releases, new incremental functionality. Just
        like release have happened so far.

    Z = crucial fix, security fix or serious "quick fix".
        Let's say 1.0.0 got released, but somebody later ran into
        a serious problem. An immediate correction release is published 
        as 1.0.1

My overall impression is that there is no urge to release 1.0 and "be
stuck with it", because bzr user base really isn't very large at the
moment. 3rd party tools are also few and sparse. 

I would like to ask developers to get together into the meeting to
discuss if it would be appropriate to bundle/integrate all or part of

  bzrtools

functionality into the core before deciding 1.0 release. It's always a
big hassle to upgrade bzr and bzrtools, because you easily forget that
bzrtools is a separate thing and then you start getting those helpful
warnings.

Jari