I agree (maybe because that was almost what I suggested, but with
different words). :)
On Tue, 25 Jan 2011 20:03:04 -0200, Howard Lewis Ship <[email protected]>
wrote:
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]
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
