Bernd Fondermann wrote:
For the next release I would like to
+ have basic (whatever than means) IMAP stable, perfoming and
functional, and well integrated with the rest of James architecture.
+ have more online management and monitoring features done
+ have a Spring distribution besides the other packages
I whould also like to focus on a branch date. Maybe branch in 2/2007 ?
I would rather not call for a "branch date", but focus on "feature
freeze" and "release" dates.
I admit I considered "branch date" = "feature freeze date".
Branching is just a technical thing which can be completely omitted if
we release from trunk.
And I would like to have us release from trunk, because it keeps us
focused on testing and finalizing.
-1: people would start head sandboxes and this is not better than having
a release branch. v2.3 proved us that working on new features on trunk
we found a lot of bugs that was in v2.3 (waiting or avoid work on other
folders does not make a codebase more solid).
Would a release target date end of Q2/Y07 be OK?
When do you propose to feature freeze to achieve the Q2 release date?
----
And here was the long one for people with more time:
Unfortunately we can only tune the branch date because we control this
event, but we have not the same degree of control on the release date:
imho we can define when we branch, bug reports, bug investigation, bug
resolutions will instead define the real release date. We can try to
estimate it but it is much more easy to speak about branch (feature
freeze) dates.
And yes, when I say "branch for release" I mean feature freezing. New
features will go in trunk, and we branched to consolidate. Imho when we
declare feature freezing we HAVE TO branch. We have 2 options:
consolidate the feature freezed code in the branch, or switch "head"
development to another branch to be merged once released. I prefer the
first. I'm sorry I took this as a fact because I saw we did this way in
past. If we want to change I'm not completely against the second option.
I'm instead against feature freezing without branching, because this
would mean completely stop any other parallel activity while
consolidating trunk (waste of contributor time).
Back on topic: What plan do you propose to try to release by end Q2?
When to feature freeeze? What kind of backward compatibility? What
"major" features to include? E.g: Would you accept a new mailet api
inside this release? Would you include a big spoolmanager change? Would
you include major refactorings?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
