El jue, 12-07-2007 a las 12:10 +0200, Ate Douma escribió: (...) > For Jetspeed 2 this discussion is quite more complex as usually a new > release of Jetspeed 2 adds many new features and improvements > effecting many of its components, including the shared jetspeed-api. > In practice, this makes switching to independent releases for each of > the Jetspeed-2 components less useful. And imagine having to vote upon > 20+ independent artifacts to be able to release a new version of the > Jetspeed-2... Not really my idea of fun, the current release procedure > is very time consuming and elaborate enough already. >
My idea was not to release separately, but to label separately. Basically, from a point onwards, each artifact has it number bumped only when its code changes (you could imagine using the minimal SVN release for which the code changed as the moment to "bump" the number. So, if a given bridge depends on jetspeed-api.jar-2.1.0-504234 (say, present in j-2.1.1 untouched), and next jetspeed minor release (say 2.1.2) does not change the API at all (it shouldn't), then this bridge can stay compatible even with a changed jetspeed release, as the old jar holds. This was my point. With such a numbering scheme, the bridges release could have stayed there, as it would have depended on the same (non-bumped, or last bumped two weeks ago) jars. I'm not sure if I'm making sense. If the dependencies are restricted to a small number of APIish jars, it could make sense to keep them as stable as possible. Something like J-api-2.0.0 or 2.1.0 that stays stable for more than one release. But I agree that it is not easy to do at all. Regards Santiago > Nonetheless, for specific situations like minor fixes or independent > (component internal) enhancements, it might be useful if a Jetspeed-2 > component could be > released independently as well. > > But one big issue I'm seeing with going with independent component > releases is how to handle that with JIRA. Our JIRA setup for > managing/marking releases might need to explode then: as you can't > version components in JIRA we might be facing splitting up the JIRA > projects in an unmanageable amount of "sub" projects. I think Cocoon > project is currently planning to do this for their (many) blocks > components, but I'm afraid this is going to be very confusing and > definitely not very helpful for end users. Not sure about this yet, > but if JIRA cannot be configured to handle separate component releases > properly, I might want to stick with our current solution after all. > I see the JIRA problem, as keeping separate artifact numbers would make tagging the bugs a bit more difficult. > I'm definitely willing to discuss this further though so feel free to > come up with a proposal for a practical solution :) > > Regards, > > Ate > > > > --------------------------------------------------------------------- > 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]
