geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Organization and versioning of specs; a new proposal
Date Thu, 17 Aug 2006 02:41:22 GMT

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.

I read this as more of a policy discussion as the topic is really,  
"how do we want to layout specs now and in the future and how do we  
branch and tag them on release."

Let's do like we did on this thread: 
In other words, create a new version of the proposal that's more  
detailed and incorporates the feedback from the original, then put it  
up for a vote.

Jason, you want the honors?


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