I agree that it might make sense to allow sub-projects to release independently of the core releases.
For instance, intellij release many EAP versions of their editor which have a small set of "core" plugins that they maintain themselves and the rest of the plug-in authors eventually catch up when they can. It sounds ironic to have a "component oriented" framework that can't have independent parts/releases going out. ;) I do see how it may start to become a major headache to worry about too many sub-projects and how they sync up with the core but it's also a great place to allow committers to work on the project and stretch their coding muscles.. Ie I think it will be healthy for Tapestry to allow ~some~ leniency in allowing people to own their own sub-projects without having to be overly accountable to the main release cycle. (there are of course some add-ons that do make since to keep in sync with the mainline releases as they are so commonly needed /critical to every day use of the framework, such as the hibernate support....but OSGI could probably certainly get away with being released separately. ) You could even go as far as having a specific core "tapestry add-ons" (or similar sounding) project web site where it is made clear which add-ons are core to the framework and something people can expect to always be present/up to date for every release and which add-ons are independently released. Anyways, there was another thread not too long ago asking what could be done to get more developers actively involved and I think allowing people to work somewhat independently on sub-projects could be a very easy way to make this happen. (also becomes easier for people like Howard to occasionally view a commit log message on a sub-project without necessarily feeling like everything ~must~ be poured over carefully if it isn't a core framework/add-on kind of commit) Can't have the development team grow and get better at designing things as it would "be preferred" without having an outlet for them to do so that isn't as strict/critical as the core libraries. imho.. On Tue, Jul 15, 2008 at 12:06 PM, Hilco Wijbenga <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 11:20 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: >> I'd rather we have a process where we can come out with a 5.1, 5.2, >> 5.3 release every few months. That's my vision, anyway, add a couple >> of significant features, work towards a GA release, lather rinse >> repeat. > > Wouldn't that then also allow subprojects to release in between using > 5.1.x, 5.2.y, etcetera? I mean, can't we have both? It doesn't seem > too difficult to come up with some sort of scheme that allows > subprojects to release bug fixes right away without losing the ability > to easily identify what Tapestry release the subproject belongs to. > > (The next Tapestry release could then bump everything up to 5.z so > that all versions are the same again.) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry / OGNL / Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
