Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
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.
There doesn't have to be an incompatible API change to make something
revolutionary. When several people have different views on how to
implement the same feature then that meets the definition of
revolutionary. Put each idea in a separate branch, let them evolve and
then let the community make the decision about what to merge with trunk.
ok, so there wasn't several people, and the debated feature could have
been taken out, but the veto specifically specified to leave it in, and
never changed.
so again, I don't/didn't see anything revolutionary in trunk,
one has yet to point to a specific feature or .java file to declare the
revolution
Filip
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.
If there isn't any disagreement on the API or the implementation then
why not put the new feature straight into 6.0.x? I don't see a problem
with having some beta features in 6.0.x as long as they doesn't
interfere with the existing functionality.
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.
API changes - I agree. API additions I have no problem with in a dot
release.
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
Anything that starts in 6.0.x and becomes revolutionary or is
perceived as revolutionary can be copied to a branch and reverted in
6.0.x. One of the nice aspects of svn is that it makes this so much
easier and cheaper than it was was cvs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
