geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Organization and versioning of specs; a new proposal
Date Thu, 17 Aug 2006 15:05:26 GMT
I'm ok with dropping it.

-dain

On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote:

> I have always been in favor of dropping any uber-jars.  They cause  
> more problems then they are worth.
>
> As for RTC... I am not so sure that this applies really.  Its not  
> going to surprise anyone, its not adding any new code... just  
> fixing up the poms and moving a few bits around in svn.
>
> But, I can jump though the RTC hoop if that is what the PMC  
> wants... I think its a waste of time... mostly mine.
>
> --jason
>
>
> On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote:
>
>>
>> On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
>>
>>> What is the status on 1.1.1 wrt this change?  Can I go ahead and  
>>> make these changes?
>>
>> My reading of Matt's note (which I agree with) is that you should  
>> wait until 1.1.1 has been shipped (unless 1.1.1 runs into an  
>> extended delay in releasing due to administrative matters).
>>
>> I think this change should follow the RTC process. This is not a  
>> bug fix, not a doc change, etc. It's updating svn and changing the  
>> way we deliver specs -- my read is that it falls under RTC.
>>
>> You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's  
>> currently versioned using the top-level pom version. I assume you  
>> plan on adding a geronimoSpecsJ2eeVersion?
>>
>> Your process for updating the jms spec would be:
>>
>>     cd specs/geronimo-spec-jms
>>     mvn release
>>     cd ../geronimo-spec-j2ee
>>     mvn release
>>
>> I'm not so sure that this is any better than we have now... I see  
>> two options:
>>
>> 1) drop the uber-jar
>> 2) release all specs simultaneosly (even if they haven't changed)  
>> and all have the same version...
>>
>> --kevan
>>
>>>
>>> --jason
>>>
>>>
>>> On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
>>>
>>>> Jason,
>>>>
>>>> I'm +1 on the change.  In order to release 1.1.1 we need to  
>>>> release an updated version of the J2EE_JAAC specs.  I am waiting  
>>>> for feedback from Geir on some licensing issues as well as a TCK  
>>>> run that Kevan is doing.  That said I'd prefer to wait until the  
>>>> we cut the 1.1.1 release.  If it looks like its going to be  
>>>> delayed due to the licensing concerns then we should do this  
>>>> straight away next week.
>>>>
>>>> Since this isn't a code change I agree with Jason's comments on  
>>>> no review required.  Lazy consensus is appropriate here.
>>>>
>>>> Jason Dillon wrote:
>>>>> A while ago there was talks about independently versioning  
>>>>> specs, and Alan started a reorg branch which gives each spec  
>>>>> module its own trunk+branches+tags...
>>>>> I have been thinking about this for a while, and with the  
>>>>> recent desire to split off more modules from geronimo/trunk  
>>>>> I've been pondering it even more.  What I have come to believe  
>>>>> is that spitting up spec modules into their own trunk+branches 
>>>>> +tags is probably not the best direction for us to head in.
>>>>> I believe that all of our specs can, and should, share one  
>>>>> trunk... and still have each module specify its own version.   
>>>>> This is very similar to how Maven2 plugins is setup, see here:
>>>>>     http://svn.apache.org/repos/asf/maven/plugins
>>>>> Each plugin has its own version that changes independently.   
>>>>> The top-level pom has a version too, which is independent and  
>>>>> is only changed when there is a major configuration change in  
>>>>> that pom.
>>>>> I recommend that we follow this model for our specs.
>>>>> The advantage to one trunk, is that it facilitates easy check  
>>>>> out and building when you just want all of the specs.  If each  
>>>>> spec was in its own trunk, you would need to svn co each one,  
>>>>> then mvn install in each tree, which is a pain.
>>>>> We also almost never branch specs, they just keep chugging  
>>>>> along, only really needing tags to track released versions.
>>>>> So, here is what I propose:
>>>>>     specs/trunk/pom.xml
>>>>>     specs/trunk/<artifactId>
>>>>>     specs/tags/<artifactId>/<version>
>>>>> And if needed:
>>>>>     specs/branches/<artifactId>/<name>
>>>>> This is a single trunk so to build all specs:
>>>>>     svn co https://svn.apache.org/repos/asf/geronimo/specs/ 
>>>>> trunk/ specs
>>>>>     cd specs
>>>>>     mvn install
>>>>> To release an individual spec, say geronimo-spec-jms:
>>>>>     cd specs/geronimo-spec-jms
>>>>>     mvn release
>>>>> The m2 release plugin can be configured with a _tag base_,  
>>>>> which we can set to:
>>>>>     https://svn.apache.org/repos/asf/geronimo/specs/tags/$ 
>>>>> {pom.artifactId}
>>>>> When released, the plugin will svn cp just the module's  
>>>>> directory into a directory under tags, so it will be easy to  
>>>>> see what the released versions of a specific spec are.
>>>>>  * * *
>>>>> I really do not see the need for each spec to have its own  
>>>>> trunk, and really I think that if we did then it would just  
>>>>> make it more difficult for cases when we really want all specs.
>>>>> I do not see any downside to the approach above.
>>>>> I recommend that we implement this.  The only major change,  
>>>>> which isn't that major, is that the properties which live in  
>>>>> the root pom that control the versions need to be removed... or  
>>>>> rather moved back to the <version> element of the respective pom.
>>>>> Comments?
>>>>> --jason
>>>
>>


Mime
View raw message