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