geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: One version for specs
Date Mon, 02 Oct 2006 18:11:24 GMT
Remeber now.... A release is jar + pom configuration. 



-----Original Message-----
From: "Alan D. Cabrera" <>
Date: Mon, 2 Oct 2006 06:51:20
Subject: Re: One version for specs

I don't think that this is a good idea.  Versions should reflect the  
contents of the jar not the fact that an unrelated spec was released/ 


On Oct 1, 2006, at 4:07 PM, Jason Dillon wrote:

> Hi, me again... and the specs topic again too.
> I have been thinking about this for quite a while and I believe  
> that it would be in the best interest of the project to treat our  
> specs as a project and use one version to release the spec modules  
> under.
> Doing so will greatly reduce the complexity to maintain the specs  
> tree and to make new releases.  It also reduces the need for a  
> bunch of config in the root pom.xml for specs... all properties can  
> be removed and most of the dependencyManagement can be removed as  
> well.
> Releases can be done using the release plugin with out any twists  
> of configuration, which should be straight forward.  The  
> alternative is that the configuration becomes more compkicated and  
> that in order to make a release users will have to have much more  
> knowledge of how Maven works and how we have configured it... which  
> I am betting will only lead to something being missed which will  
> only lead to problems down the road.
> One thing to remember for those of you who are gonna say that some  
> spec module has not changed in x-years... is that the release is  
> code + pom configuration... and even if the code has not changed,  
> the configuration has, and thus it warrants a new release to be made.
> Specs do not get released that often anyways, so I don't really see  
> any huge problem with re-releasing specs under a new version when  
> something is added (or fixed).
> 1 version number for us (and our users) is IMO much, much simperer  
> than 30+ versions.  For example, if I am a developer and want to  
> use the latest versions of all of the specs that I use, I would  
> much rather know that there is just one version to track, instead  
> of needing to hunt down what the latest version of each spec is...  
> after all I don't care what the version is... I just want the  
> latest version.
> Also remember that some spec modules depend on other spec modules,  
> so ideally when a dependency module is released, the dependent  
> modules should be released to pickup the latest versions.  Doing  
> this is automatic with the one-version scheme, but becomes much  
> more work with independent versions... which will almost certainly  
> result in dependent modules not getting updated as they should.
>  * * *
> We have also been waiting for some resolution on this to simplify  
> the main server build.  It will take all of 10 minutes for me to  
> fix the specs build to use one version and make a release than can  
> be used by the server build (and allow the bootstrap of specs to be  
> removed).
> So, my recommendation is to:
>   1) change the specs project to use one version, 2.0-SNAPSHOT, and  
> publish the snaps
>   2) update the server build to use 2.0-SNAPSHOT for all specs
>   3) remove the specs build from bootstrap
> I believe this is the best option for the project and community at  
> this point.  I would like to implement this ASAP to simplify the  
> server build.  If after some time folks do not feel that is working  
> well, then we can revisit and consider either splitting up into a  
> multi-trunk build or using independent version numbers.  But, I do  
> believe that most will find that the advantages of using one  
> version far out-weight the disadvantages.
> For those unaware, Dain did an experiment with version ranges...  
> but it looks like this will not work well right now as there is not  
> general support for use of ranges in most plugins that we depend  
> on.  Also several members of the m2 team have suggested that ranges  
> are buggy.  This was my general impression that I brought up to  
> Dain weeks ago when we talked about using ranges (and when he said  
> he would try it out).  So, for now at least I think that ranges  
> will not work for us.
> --jason

View raw message