geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject One version for specs
Date Sun, 01 Oct 2006 23:07:47 GMT
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.

NOTE:

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



Mime
View raw message