geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: One version for specs
Date Tue, 03 Oct 2006 17:59:16 GMT
I take it that you are arguing that since the POM changes then the  
release jar has actually changed.  This argument already assumes that  
you're using a single version for specs.  Do I understand correctly?


On Oct 2, 2006, at 11:11 AM, wrote:

> Remeber now.... A release is jar + pom configuration.
> --jason
> -----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/
> 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

View raw message