Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 46794 invoked from network); 7 Feb 2007 13:32:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2007 13:32:49 -0000 Received: (qmail 64221 invoked by uid 500); 7 Feb 2007 13:32:54 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 64143 invoked by uid 500); 7 Feb 2007 13:32:54 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 64131 invoked by uid 99); 7 Feb 2007 13:32:54 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 05:32:54 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [70.168.83.83] (HELO centrmmtao01.cox.net) (70.168.83.83) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Feb 2007 05:32:43 -0800 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao01.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070207133221.SAYM24316.centrmmtao01.cox.net@eastrmimpo01.cox.net> for ; Wed, 7 Feb 2007 08:32:21 -0500 Received: from [192.168.0.100] ([24.255.120.190]) by eastrmimpo01.cox.net with bizsmtp id LdYM1W00U46aSr40000000; Wed, 07 Feb 2007 08:32:21 -0500 Message-ID: <45C9D4CA.8080203@reverycodes.com> Date: Wed, 07 Feb 2007 08:31:54 -0500 From: Vadim Gritsenko User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Releasing from trunk References: <45C35D42.4030405@apache.org> <45C8ABF6.1080003@reverycodes.com> <45C97C25.30903@apache.org> <75D3329A-FB1C-4184-8E5E-9A8DCDAF1377@luminas.co.uk> <45C9A82C.1040502@apache.org> In-Reply-To: <45C9A82C.1040502@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Carsten Ziegeler wrote: > Andrew Savory wrote: >> Hi, > >> Not wishing to spread FUD and rain on the parade, but ... I think 2.2 >> is *massively* less tested than 2.1.x. The main reason 2.1.x goes out >> with not much testing is because it's been used in production by a >> very large number of people. How many are actually using 2.2 in >> production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess >> at most < 10 sites? >> >> I'd love to see 2.2 out the door and more people using it, but I'd >> also hate to see people's first experience of 2.2 be a buggy one. >> >> Given that we're still seeing changes enough to kill Cruisecontrol, >> I'd suggest an 'M' is more suitable than an 'RC'. +1 >> And yes, I'm putting my money where my mouth is and trying to use 2.2 >> to build a site ;-) >> > Great :) > > We need to get a 2.2 out; imho it is more important to have something > out after so many years than having a 115% bug free version. You are missing a point. It's not about a bug free version. It is about a version which seen more than like 4 hours of testing after major surgery. > In addition, there is no guarantee that releasing a milestone will bring > us more users testing, more documentation etc. And I personally doubt > that people will start trying a milestone release. Counterpoint: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843 They are not even trying, they are using it in production. It is a bit different for 2.2 though: there were no "real" downloadable release yet, so there is really no easy way to download 2.2 and give it a spin on existing 2.1 project. High entry point would hamper wider adoption of 2.2, not the label on its release. > And what will be the exit criteria? When do we have enough confidence > (if it is really missing today) that we are stable enough for switching > from milestone to rc? We only have indicators and feelings. I think that > the current code base is stable and the work we are doing with is a > proof for this (for me). When there is a consensus in the community that version is ready for RC or Final release. Given the responses so far, you already can see that to reach consensus we'd have to: * have some more testing done (not 4h or 1d as now), * have unit tests working, * have CC working and not failing over, > On the other hand, a RC does not mean bug free - it means stable from > the api and implementation pov. If we would be sure that it's bug free > we could release a final right way. Agree. > Yes, we had several changes in the last days/weeks, but doing a RC gives > ourselves the responsibility to not change these things until we have a > final version out (or create a branch). Do you mean to say you can't stop doing major refactoring and start polishing unless it bears RC badge? What happened to good old-fashioned discipline and self control? :) Vadim > So, in short: a RC is an indication to *everyone* that this is the a > stable version from the api pov and that we think (or hope if you like) > that this version is stable as well. It's more likely that people will > try out an RC than a milestone. So if we get feedback back at all, this > will happen for an RC but never for a milestone. > > Carsten