I like the 2) option with new code under
https://svn.apache.org/repos/asf/tapestry/tapestry5-module-name, maybe
inside https://svn.apache.org/repos/asf/tapestry/incubation, /extras or
some other folder name so we can easily see what's part of which, not
inside /trunk.
On Tue, 25 Jan 2011 19:38:59 -0200, 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]
--
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]
