[dev] Release plan

[Jan Schneider]

Zitat von Chuck Hagenbuch <chuck at horde.org>:

> 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.

Agreed. This should be done before the BETA releases because I want them to
be as API stable as possible.

> 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.

Right, Text is a good example.

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

Where does the new Date package stand? Do we use it already?

Relationship probably needs more work and being integrated into the
applications?

I can't think of anything else at the moment.

Jan.

--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/