geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: One version for specs
Date Mon, 02 Oct 2006 19:38:39 GMT
IMO there is no "best" way to handle this problem.  There is only  
good and bad for each solution, but there is no smoking gun to solve  
everyones issues.

I already sent out that itty bitty note about the release being jar +  
pom(s) but I wanted to clarify that even more...

If you take the current specs build... all of the versions of the  
specs are defined in the top-level pom, which means that whenever any  
module need to change, that its parent will also need to change, and  
that change to its parent may cause other specs to need to be changed  
(if they depend on the spec that has been versioned).  Those  
dependent modules really should be released in the same process too,  
but there is no easy mechanism to automate that in the multi- 
versioned build.  Which leaves that task up to process... and as I  
have mentioned before, will almost certainly result in problems due  
to lack of insight into maven and how the multi-version spec build  
functions.

If we have each spec in its own tree, that means that nothing is  
shared and all referenced version numbers are hardcoded, which means  
that when a dependency module is released that it is up to the  
process again to make sure that each dependent module gets updated  
and then released... which is even more problematic for keeping  
things in-sync and now users need to have even more insight into how  
the specs related to each other and will almost certainly end up in  
disaster, especially as more specs are added and more so when  
developers come and go.

Both multi-version schemes seem to end up going down the same path  
towards a maintenance nightmare.

But, if you compare this with the one version... if a dependency  
module changes, then all dependent modules will automatically get  
configured with the right version, will be included in the tag, will  
be included in the docs (site stuff), will be published and all of  
this can be done in a few simple steps... all of which are standard  
m2-isms so anyone who knows m2 should be able to easily understand  
what is going on.

I agree with you on some levels... and in a perfect world maven would  
be able to make this happen for us as easily as it can with a single- 
version scheme... but right now this is not the case.  Maybe in 6mo  
or a year maven will have a solution for us, but today it does not.

  * * *

It is still my recommendation that it is best for the project in the  
short to medium term that one version be used to manage specs... and  
to commit to revisit later when there is better support for multi- 
versioned build automation.

--jason


On Oct 2, 2006, at 6:51 AM, Alan D. Cabrera wrote:

> 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/patched/updated.
>
>
> Regards,
> Alan
>
> 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