0.8.3 bugfix release

[Martin Pool]

On 18 Jun 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:

> > So the question is, how much effort do people think it will be to get
> > bzr.dev into a releasable state? If that is too much, what should go
> > into 0.8.3?
> 
> The short answer is:
> 1) Undeprecate all_revision_ids, we're pretty far off from not actually
> using it. (mostly because of ghost support)

I think that would be fine; anyhow most of the callers are inside bzrlib
and so the deprecation is not very interesting.  I'll pull it back out
if noone objects - we can still move towards reducing the number of
callers.

> 2) Have the EncodingAdapter skip the tests on Mac. Or only use the
> unicode entries that don't have alternate combinations. (Use µ rather
> than å)

I'm also seeing a failure in the bundle tests on mac, because of the
unicode canonicalization you diagnosed.

> I agree that a point release seems like it should be a smaller set of
> fixes (than almost 80 mainline commits). I just don't see why we would
> want to through out good progress. We don't have any actual regressions.
> Just a few new warnings about things we (still) don't fully support.

I'm generally inclined to try to keep things moving forward rather than
backporting or cherrypicking work.

Also I think 0.x.y releases really should be small "oops, we messed up"
bugs.  Some releases will be bigger than others so the question is do
you want the point releases to sometimes be large or the minor releases
to sometimes be small?  On the whole it's better that people know point
releases are really likely to be safe.

So I propose we try to stabilize and release 0.9 before the end of June
and see if any portability things can be fixed then.

-- 
Martin