Mark Thomas wrote:
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other words, how do achieve
agreement on APIs?
http://incubator.apache.org/learn/rules-for-revolutionaries.html
trunk was never a revolution, there werent even API changes, except
annotations. The comet stuff was API additions, but 100% backwards
compatible with the old stuff.
by now we are all familiar with the rules for revolutionaries, but that
has never been the issue around here.
Mostly we are talking about new APIs for new features that, once
agreed, can be added to the current version.
It is changes to existing APIs that are more problematic. The current
APIs will need to change occasionally (eg the Geronimo changes) and
will need to be a new point version (6.1, 6.5 - whatever).
We are already managing:
- 4.1.x (mainly security and the odd bug)
- 5.0.x (security only but needs some header work before release)
- 5.5.x (security, bugs, some back porting of features)
- 6.0.x (security, bugs & new features)
Maintaining, to various degrees, 4 branches is already a fair amount
of work for the team. I don't want to see more maintained branches
than absolutely necessary.
What this means is we need a set of agreed API changes for 6.0.x that
will eventually become 6.1.x/6.5.x. I see
http://incubator.apache.org/learn/rules-for-revolutionaries.html as
the way to get this agreement.
actually, preferrably it would be the other way. API changes and new
features go into trunk, and if deemed useful,agreed upon, they get
backported to 6.0.x.
I find it not healthy to deal with API changes on dot releases (kind of
like the digester), especially once a branch is labeled as a stable
release branch.
stuff like that goes into trunk, to avoid necessary delays of security
patches and bug fixes to go out as a release.
otherwise, you'll have revolutions in 6.0.x that turn into evolutions in 6.x
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
