On Tuesday, September 29, 2009, Jeremy Hughes <[email protected]> wrote: > 2009/9/29 Guillaume Nodet <[email protected]>: >> I've no idea yet ;-) >> Having a single trunk does not necesseraly mean we release everything >> together. >> Felix works this way and maven plugins too (or at least they used to). > > How does this work w.r.t subproject interdependencies ... how does a > user know what levels of the subprojects have been tested with each > other are are known to work together. e.g. [email protected] depends on has been > tested with [email protected] ... a new [email protected] is released but how do users > know whether they're ok using [email protected] with [email protected] ? The combinations > can get mind-boggling. Perhaps it just works!?!? I don't know Felix > well enough to say.
We have the maven dependecies plus the osgi package versioning and constraints to deal with those problems, so I don't think the argument holds. > Initially I would prefer to release all of what we have together so > there is no confusion with users. As the project grow we can revisit. I think it's quite difficult to balance anything related to the release cycle right now, and we should wait a bit until more code comes in and see how to organize it. But given the blueprint implementation is already consumed by other Apache projects (mostly Felix Karaf for now afaik), it might make sense to keep separate release cycle to be able to release new features or bug fixes more easily. Having more fined grained releases makes it easier to keep up with the "release early, release often" mantra. In Felix, it seems to work quite well. Of course, the drawback is that there are often releases to review and vote on, but it does seem a big problem. So, in conclusion, if components are highly tied together, it makes sense to release them together: for example transactions support for blueprint should imho be released along with the blueprint core implementation. But an RFC 66 implementation and blueprint do not have to be released together. But I think the svn organization question can be somewhat separated from the release cycle of the different components, and the maven release plugin can deal with a single trunk without any problems. >> >> 2009/9/29 Alan D. Cabrera <[email protected]>: >>> >>> On Sep 29, 2009, at 5:51 AM, Guillaume Nodet wrote: >>> >>>> I've set up the default structure for the svn tree so that we can have >>>> a git mirror for those that are interested in using this. >>>> >>>> The svn repo is available at: >>>> https://svn.apache.org/repos/asf/incubator/aries/trunk >>> >>> >>> Are we going to release blueprint in tandem with the rest of the Aries >>> products? >>> >>> >>> Regards, >>> Alan >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >
