Remeber now.... A release is jar + pom configuration. --jason
-----Original Message----- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Mon, 2 Oct 2006 06:51:20 To:[email protected] 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 > >
