geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Organization and versioning of specs; a new proposal
Date Wed, 16 Aug 2006 14:13:01 GMT

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  

1) drop the uber-jar
2) release all specs simultaneosly (even if they haven't changed) and  
all have the same version...


> --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:
>>> 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  
>>> 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:
>>> {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

View raw message