interface deprecation/removal policy

[Martin Pool]

John wrote, in <https://code.launchpad.net/~mbp/bzr/deprecation/+merge/12262>

> > It's not a big deal and we can certainly retain it fairly cheaply.
> > It's more just dead code than something that's actively getting in the
> > way.
> >
> > However, I do think (and have said) the stable branch does give us
> > licence to rip things out of bzr.dev.  I'd rather things were taken
> > out now than when we're nearing 2.1rc1.
> >
>
> I agree that removing deprecations in the 'beta' phase versus the 'rc'
> phase seems wise.
>
> HACKING still says this:
> Evolving Interfaces
> ===================
>
> We have a commitment to 6 months API stability - any supported symbol in a
> release of bzr MUST NOT be altered in any way that would result in
> breaking existing code that uses it. That means that method names,
> parameter ordering, parameter names, variable and attribute names etc must
> not be changed without leaving a 'deprecated forwarder' behind. This even
> applies to modules and classes.
>
>
> Which means that things deprecated before 2.1b1 would be removed at 2.2b1...
>
> Then again, we can say that if you want the stable w/ deprecations
> branch, use "bzr.2.0.*" instead...

John's quite correct that, if this was merged, we'd not be doing what we said
we would do.

I think we should consider that policy obsolete by the stable branch thing.
Possibly we should keep honoring it for six months after we change the policy,
but then we _are_ going to do that: just on the 2.0 branch not 2.1.

We should at any rate update the doc.

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