[dev] Release plan

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> I reconsidered the original branching plan and will now try to avoid
> branching as long as possible, ideally until the final releases, for two
> reasons: To avoid the hassle of merging as long as possible, and to force
> us to spend our time on bug fixes. This goes a bit beyond the nature of
> volunteer oss development but this phase will only last for a few weeks and
> we won't get the releases out of the door in this life otherwise.

I agree, especially about forcing ourselves to work on bugfixes (though not in
newer apps, of course).

I'm reluctant to extend the time we take for this at all, but I want to 
propose
another stage: an API-review stage, where we look at APIs and other design
elements that we're not quite happy with that'd be hard to change without
breaking backwards compatibility. We then assess if it's something we can sort
out quickly, or if it'll just have to wait.

The best example I have for this right now is the Text:: package - there are
functions that are in Text:: that probably should be Text_Filter subclasses,
and Text_Filter was never really sorted out. I'd like to move them all into
Text_Filter before we freeze the API so that we're not forced to stick 
with the
old "throw a function in Text::" for the rest of the Horde 3 release life.

Thoughts? Objections, suggestions for other things to review? Yes/No on
Text_Filter changes?

-chuck

--
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams