I think we need to gravitate towards the approach that requires the least amount of coordination and administrative overhead. Maybe it could be different if more of the Tapestry developers were under a single roof, but adding in any kind of overhead tends to tank any attempt at a regular release schedule.
I'm comfortable with creating a new module to hold auxiliary components and services, maybe several additional modules. A sexy name for that would be nice, maybe "tapestry-extras". I'm also comfortable with the idea of new modules "incubating" out in the world and being brought into Tapestry once they've solidified. On Tue, Jan 25, 2011 at 1:38 PM, Andreas Andreou <[email protected]> wrote: > So, in order to go on with adding / accepting new modules / subprojects > (such as the cayenne integration module discussed at > http://markmail.org/message/5l7xi6srkcfwepeo ) > and have a clear vision of how things will be, let me recap the alternatives > mentioned here... > > 1) New modules live in > https://svn.apache.org/repos/asf/tapestry/tapestry5/trunk/ > Releases are performed for all subprojects at the exact same time (and hence > for the same version). This process is what we currently employ and > thus requires > no further explanation. > > 2) New modules can be created outside of > https://svn.apache.org/repos/asf/tapestry/tapestry5/trunk/ > perhaps in https://svn.apache.org/repos/asf/tapestry/tapestry5-module-name. > Releases will > not have to be performed at the same exact time for all those new > subprojects BUT when they > do occur they have to use the exact version number of the tapestry > core modules they target. > The differences in this process are: > a) each module gets its own truck, branches and tags. This allows the > module to also release > versions compatible with older tapestry versions if there's such a > need (so tapestry-cayenne can > release a 5.2.x version) > b) timing of the releases doesn't have to coincide 100% - so, > "unfinished" subprojects don't have > to stall the rest of the releases. Additionally, it becomes easier to > accept "experimental" > subprojects > c) it might not be possible to guarantee same release numbers in all > subprojects - that > would result in maintenance and support problems as well as user frustration > > Now, we haven't run a vote on which to choose as my original intention > in this thread > was to get a first understanding of what the other devs think on the > matter. From > the responses, I get that most prefer to keep things as described in > 1), so there's no real > point in running a vote... but as i said, it's good to see where > everyone stands :) > > Thx. > > > On Fri, Jan 21, 2011 at 19:47, Massimo Lusetti <[email protected]> wrote: >> On Fri, Jan 21, 2011 at 6:47 PM, Massimo Lusetti <[email protected]> wrote: >>> On Fri, Jan 21, 2011 at 6:34 PM, Howard Lewis Ship <[email protected]> wrote: >>> >>>> I also agree; we now have consistent tests to ensure that tapestry-ioc >>>> 5.3.7 works with tapestry-core 5.3.7 works with tapestry-spring 5.3.7. >>>> If each had its own version, you end up in a situation where you need >>>> complex tables to try and guess which version goes with which other. >>>> I guess inter-module dependencies may streamline this, but I think it >>>> still is more complicated than having a consistent version number. >>> >>> Having a separate release engineering is totally different from >>> version number but I agree with the fact that a precise and consistent >>> dependency management. >> >> ... a precise and consistent dependency management have to be present >> before starting to separate projects. >> >> Cheers >> -- >> Massimo >> http://meridio.blogspot.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Andreas Andreou - [email protected] - http://blog.andyhot.gr > Tapestry PMC / Tacos developer > Open Source / JEE Consulting > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
