geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Organization and versioning of specs; a new proposal
Date Fri, 11 Aug 2006 19:44:42 GMT
This feels like an excellent compromise where we can easily build  
them together and they can be independently versioned.


On Aug 11, 2006, at 12:15 PM, 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