tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiago H. de Paula Figueiredo" <thiag...@gmail.com>
Subject Re: Tapestry subprojects (was: [jira] Commented: (TAP5-1421) Create a standard way to track messages to be presented to the user)
Date Tue, 25 Jan 2011 22:04:44 GMT
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 <andyhot@di.uoa.gr>  
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 <mlusetti@gmail.com>  
> wrote:
>> On Fri, Jan 21, 2011 at 6:47 PM, Massimo Lusetti <mlusetti@gmail.com>  
>> wrote:
>>> On Fri, Jan 21, 2011 at 6:34 PM, Howard Lewis Ship <hlship@gmail.com> 

>>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>


-- 
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message