From dev-return-39459-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Mon Oct 02 13:52:05 2006 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 63912 invoked from network); 2 Oct 2006 13:52:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Oct 2006 13:52:04 -0000 Received: (qmail 88241 invoked by uid 500); 2 Oct 2006 13:52:00 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 88192 invoked by uid 500); 2 Oct 2006 13:52:00 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 88177 invoked by uid 99); 2 Oct 2006 13:52:00 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Oct 2006 06:52:00 -0700 X-ASF-Spam-Status: No, hits=0.1 required=5.0 tests=X_PRIORITY_HIGH Received: from [72.10.46.63] ([72.10.46.63:39503] helo=as.toolazydogs.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id BB/BA-16499-77911254 for ; Mon, 02 Oct 2006 06:51:57 -0700 Received: (qmail 20224 invoked from network); 2 Oct 2006 06:51:28 -0700 Received: from c-24-7-76-123.hsd1.ca.comcast.net (HELO ?192.168.1.102?) (24.7.76.123) by toolazydogs.com with (AES128-SHA encrypted) SMTP; 2 Oct 2006 06:51:28 -0700 In-Reply-To: <77D3BF90-B687-4DD8-A7EF-260828356870@planet57.com> References: <77D3BF90-B687-4DD8-A7EF-260828356870@planet57.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 1 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A52B452-ED6C-4934-A44F-DB60586C8D1C@toolazydogs.com> Content-Transfer-Encoding: 7bit From: "Alan D. Cabrera" Subject: Re: One version for specs Date: Mon, 2 Oct 2006 06:51:20 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 > >