Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 71766 invoked from network); 17 Oct 2008 01:40:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Oct 2008 01:40:55 -0000 Received: (qmail 86886 invoked by uid 500); 17 Oct 2008 01:40:55 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 86826 invoked by uid 500); 17 Oct 2008 01:40:55 -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 86815 invoked by uid 99); 17 Oct 2008 01:40:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2008 18:40:55 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kevan.miller@gmail.com designates 66.249.82.235 as permitted sender) Received: from [66.249.82.235] (HELO wx-out-0506.google.com) (66.249.82.235) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Oct 2008 01:39:47 +0000 Received: by wx-out-0506.google.com with SMTP id r21so133051wxc.25 for ; Thu, 16 Oct 2008 18:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=XipxltEo1l0CUAMkQZ3p+dbxxB2/aBAg/n5lMbXx4GE=; b=fPPKDyT6ILk8JW+h2TUBSBrXW7nx1hGW7vKXsX1qBkTj1xYjrFT9+vzRJKtCmmTAOr 2rYyfCd6542cQUVa8K0gebfb8X8kk8U8QASb9U5KOk14/XXXy0TNBqwMvCUUIQzC2KWn nhYoiNdWZ/Bzo1zE3RmeWFWMdpmoxd5a8H0+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=kmRRf8dyBaR9J9DAQmXkSuaoPo5UHEc/ZZQ/Z2aXEGUe+VeQACjYxzrLatkjEppfoM g2grg2mYA9wtClOKmT0y0+Jjhjertxdg0fjx+YXfs5vxuqh4fAtfUm18ctGx12JZQJTK jxNLJZVvyuwscnWy9+80L/IYY51AiEOGGSz+s= Received: by 10.70.59.19 with SMTP id h19mr3538949wxa.17.1224207624325; Thu, 16 Oct 2008 18:40:24 -0700 (PDT) Received: from ?10.0.1.185? (cpe-076-182-095-055.nc.res.rr.com [76.182.95.55]) by mx.google.com with ESMTPS id h19sm3253881wxd.32.2008.10.16.18.40.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Oct 2008 18:40:23 -0700 (PDT) Message-Id: From: Kevan Miller To: dev@geronimo.apache.org In-Reply-To: <48F7DC1C.4090900@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Looking back to 2.0.x Date: Thu, 16 Oct 2008 21:40:22 -0400 References: <48F7DC1C.4090900@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org Hi, Jay. On Oct 16, 2008, at 8:28 PM, Jay D. McHugh wrote: > Hello all, > > With the discussion of where the JEE 6 development will be done, I > realized (again) that we never released 2.0.3. > > The only thing that kept us from releasing 2.0.3 was an exception that > only occurred under stress testing the server (a > ConcurrentModificationException). We scuttled the whole 1.2 release for similar reasons. Perhaps we should work on learning from our own history. > > > And, recently, when we added a number of security patches that were > the > driver for releasing 2.1.3 - the same security patches were put into > the > 2.0.x codestream as well. > > Should we put out one last release of 2.0.x and then officially > encourage anyone on a level lower than 2.1.x to upgrade? I think that > is probably what we should do. At this point, there is a range of > work > being applied to 2.0.x, 2.1.x, 2.2.x and soon 3.0.x (or however we > version the upcoming JEE 6). If you, and/or some other community member(s), are motivated to prepare a 2.0.3 release, you'd certainly have my support. I'm sure you'd have the community's support, also. Given the security fixes that you mention, I think it would be nice to have an actual release that contains them. > > > Also, do we have an official 'support period'? Would it be worthwhile > to discuss implementing one if we don't? Letting our users know > that we > intend to support a particular major.minor release (bug fixes only) > would make it easier for them to plan which version they want to > implement against and plan/schedule their server upgrades. Maybe we > would specify a window of '12 months after the next higher minor > release'. Version 2.1.0 was released this February, so 2.0.x > 'official' > support would end next February. Of course if someone felt like > continuing to make fixes (and they had someone to run TCKs against > them) > then 'unofficial' support may run longer. We've never established an official support period. I'm not too sure that we need one. If you disagree, then I'm all ears. Or, if our user community feels that it would be helpful, then I'd certainly give it my consideration. Personally, I think we've done a pretty good job in merging fixes back into our older releases. I haven't seen that the lack of a support policy was inhibiting user adoption. As long as we have a stable newer release (e.g. 2.1.x) release to point to, shifting our focus towards our newer releases doesn't seem too bad to me. If there had been user requests for a 2.0.x release, I think we would have generated a new 2.0.x release. > > Our resources are being spread -really- thin. And as a result, 2.0.x > has been nearly abandoned. We have security fixes that were put in > this > September, but no release in the last 12 months. When 2.2.x is > finally > released and the JEE 6 work begins in earnest - I have a feeling that > 2.1.x will begin to fall by the wayside as well. I expect that you are correct. Personaly, I doubt that we'll ever maintain more than two release branches simultaneously (e.g. 2.0/2.1, or 2.1/2.2; etc). > > Regardless - I mainly wanted to know if anyone thought that we > should go > ahead and do a final release on 2.0.x. I think the security fixes > make > it worthwhile. But then, maybe we should officially set an end for > 2.0. > > Any thoughts? I second the motion for Jay to be the release manager... ;-) --kevan