geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: One version for specs
Date Sun, 01 Oct 2006 23:31:04 GMT
After a long time thinking that separately versioned specs were  
better I started thinking about how much work it would be if I was  
trying to release separately versioned specs.  I now think we should  
at least try the one-version approach.  What we've been doing has  
resulted IMO in total confusion and many many problems releasing specs.

In any case PLEASE think about this and make your opinion known soon.

My only caveat is that I would prefer to use 1.2-SNAPSHOT releasing  
to 1.2 rather than 2.0.  I tend to regard this as finally  
straightening out what we are doing with specs, and lining up the  
versioning and release with the directory structure, rather than a  
major policy change.  (now we have a policy rather than confusion :-)

In addition I'd like to thank Jason for pushing on this issue.

thanks
david jencks

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.
>
> 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