geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Organization and versioning of specs; a new proposal
Date Fri, 11 Aug 2006 19:15:28 GMT
A while ago there was talks about independently versioning specs, and  
Alan started a reorg branch which gives each spec module its own trunk 

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:


And if needed:


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

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.



View raw message