Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OtkpyAqqidkC0cUuuVPjxvOrbMrhxrglwhcN3YAcV7UfRI9XMaD0TQZ+x3ZRR2kyHusXjlIN11MYqy4jin7sGydGuV/veL9aJdH6f9x+65DAHYB/Rs8cCk8OKepR1iecbjvEtMVFMFtqS4IBuyYgPomkwYc5JTZrCVvsiq4ataU=
Message-ID: <cc159a4a05052306527fadfb06@mail.gmail.com>
Date: Mon, 23 May 2005 08:52:43 -0500
From: Peter Hunsberger <peter.hunsberger@gmail.com>
Reply-To: Peter Hunsberger <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: Releasing 2.2 (was: [RT] Micro kernel based Cocoon)
In-Reply-To: <0da8afe941bea1f45f68a92590cbbcfe@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <428DE86B.9020106@nada.kth.se> <428F5A4C.9090003@apache.org>
	 <428F7AA4.5040901@apache.org> <4290541A.6040405@apache.org>
	 <42906B19.2060101@nada.kth.se> <42906EA9.10601@apache.org>
	 <42908034.7020209@apache.org> <4290F375.2090700@apache.org>
	 <42916663.9080005@apache.org>
	 <0da8afe941bea1f45f68a92590cbbcfe@apache.org>

On 5/23/05, Bertrand Delacretaz <bdelacretaz@apache.org> wrote:
> Le 23 mai 05, =E0 07:13, Reinhard Poetz a =E9crit :
> > ...Let's release "Cocoon 2.2 alpha1" as soon as possible. When the
> > contracts are stable we use the "beta" postfix. This will increase the
> > number of people who use and test the release and finally we can
> > release "Cocoon 2.2.0 final"...
>=20
> Releasing 2.2 soon would allow us to stop keeping the 2.1 branch in
> sync, which is a pain IMHO.
>=20
> But are there enough visible incentives in 2.2 for people to make the
> switch? Do we have cool, exciting samples of the new features?
>=20
> I'm not sure, and if we haven't, people might just keep on using 2.1,
> and the risk is having too much pressure to maintain 2.1 instead of
> being able to move on.

We tend to trail at least one release behind so that we can determine
if any major bugs show up in a new release and what it means for us to
migrate. On occasion that means we skip a release if something is
broken that we depend on (rare) or if we get too far behind.  More
frequent release of Cocoon would just mean we skip more release...

We do tend to use new features of Cocoon when we have a project
underway that results in new code on our side.  For instance, with our
next major release of our code (currently in development, with 2 other
releases in the testing pipeline in the mean time) we should finally
have everything switched over to flow (no more actions for flow
control).

It wouldn't make a huge difference to us if a final 2.2.0 was
released.  If the reports where that it was somewhat stable, then
sooner or later we'd get around to testing it and determining the
impact on our application. Once we'd could evaluate that we'd fit the
migration into our schedule. (If it's a big change, that might mean 6
months to a year before it hits production.)

Personally, I'd say JFDI; build a 2.2 alpha, only put new features in
2.2 and plan on keeping on doing bug fixes on the 2.1 branch through
at least a 2.1.9.

--=20
Peter Hunsberger