branches, bugs, and landings for 2.0 and beyond

[Martin Pool]

John mentioned in a review the idea of having a separate frozen branch
for 2.0final.  I think that makes sense, so now we have
<http://code.launchpad.net/~bzr-pqm/bzr/2.0.0> targeted specifically
at that.  In other words there are three main live pqm-controlled
branches

 2.0.0 aimed at bzr 2.0final
 2.0 aimed at 2.0.1
 bzr.dev aimed at 2.1

Bugs that are proposed to be fixed in the 2.0 stable series should
have a bug task against the bzr/2.0 series.  (Use the "nominate for
release" control.)  The merge proposal for them should propose going
into the 2.0 branch.

2.0.0 is only for any further critical fixes we might find.

What is suitable for 2.0.1?  Generally:

 * mostly bug fixes
 * nothing that changes APIs or breaks plugins
 * nothing that causes interoperation problems between 2.0* releases
 * no changes in user-visible behaviour, aside from bug fixes
 * no new hard dependencies
 * reasonably minimal code changes, for ease of review and to reduce
the chance of accidental changes
 * similar review guidelines as far as test coverage and clarity to
what we normally use

There are tradeoffs and there are going to be grey areas and special
cases, and I expect we'll get a better idea of how to navigate this as
we go along.  We're setting expectations with users and packagers so
we should stick closely to them, without being doctrinaire.

One example: the idea from talking to Alexander that we should add a
configuration option to set the default format: it's not strictly a
bug fix, but it should be reasonably safe in terms of code changes, it
should not cause compatibility problems, and it will help in allowing
some users to move onto 2.0 earlier, which is worthwhile.

Generally speaking I think all bug fixes that might possibly want to
land on 2.0 should be done based on 2.0.  It might turn out during the
course of development or review that in fact it's not appropriate to
land there.  In some cases we might want a small landing to 2.0 and a
larger cleanup in trunk.

The cleanest way to fix a bug may involve a larger cleanup, or might
involve breaking a bad API.  We'll have to work it out case by case.
Let's not waste too much time fixing the same bug two ways, or
backporting fixes.

Now that we have 2.0 branched off, trunk can move a bit more freely in
deprecating or removing old code.  Some things are hard to generate
deprecations on, and I'd encourage you to just go ahead and remove
them.  Do add a NEWS entry and do mention it in the merge cover
letter.

-- 
Martin <http://launchpad.net/~mbp/>