requirements and roadmap for 1.0

[Martin Pool]

We should have 0.90 final today (approximately), and we're then
starting on 0.91.  I'd like to look at what would make up a 1.0
release and when we can do it.

We had a couple of threads recently about version numbering.  Version
numbers are, in a sense, just arbitrary tags, from which perspective
it is confusing or pointless to change the scheme or advance the
numbers.  At least you should not be changing scheme too often.  On
the other hand, version numbers along with release notes do convey
something to users about the magnitude or importance of the changes in
a release.

1.0 means different things to different people.  I have been told by
several people recently that they're sure we're already past a 1.0
level of maturity, and we should go ahead and that 0.18 in particular
was an unrepresentative name for the maturity of that release.  On the
other hand, if you list features that would be nice for 1.0 it can be
a long way in the future.

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.

Bugs: at the moment there are 134 bugs with status 'new' or importance
'undecided' or both.  These are bugs that may not have been assessed
by a developer, though most of them will have been read and some of
them in fact have been commented on but not classified.  I think we
should try to at least triage all of them to make sure that there are
no monsters.   There are 6 critical bugs, two of which (docs and lp:)
which must be fixed.  There are 40 high importance bugs, which should
at least be reviewed to make sure they are not blockers.  People
including myself have particular hated bugs, but really the only thing
is to get in there and fix them.

Docs: one of the critical bugs is that there should be reasonably
complete user documentation for Bazaar.  I know Ian has improved this
a lot; I'm not sure how much more still needs to be done but there is
some work.

Performance and architecture: we're working hard on performance and it
keeps improving in each release.  There will be more changes in the
next 4+ releases in storage, network and tree shape areas at least.  I
don't really see a plateau coming up at which we would declare 1.0.  I
think it's ok to do a 1.0 release while we still have performance work
planned as long as we don't expect it will be impossible to do smooth
upgrades - and really, that would not be acceptable even now.

Release schedule and naming: I think we should stay on the current
release schedule, which seems to work.  Bazaar releasing every 4 weeks
does not mean all users have to upgrade every four weeks.  One other
thing I took from the version number thread is that we should perhaps
make our release notes more clear recommendations about who should
upgrade and how, and I'll send patches to do that for this upcoming
release.

Team direction: Doing all the above obviously takes time and with
people (particularly from Canonical) concentrating on performance I
don't want to distract them.  But, really, we have to do it sometime.

Announcement: You only turn 1 once, so we should make a splash about it.

Features: We have the core features and that's enough for 1.0.  We can
add lots more.

So it seems to me the main things that need work are reviewing and
triaging bugs, fixing bugs, and finishing documentation.  John was
trying to triage 10 bugs per day and encourage others to.  If just a
few of us can keep that up we can clear that list in a couple of
weeks.

How about this map, each as typical-sized releases:

  0.91 September - you're soaking in it
  1.0rc1 October - code complete for 1.0, onto a separate bugfix-only branch
  1.0 November

-- 
Martin