On 5/23/05, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Le 23 mai 05, à 07:13, Reinhard Poetz a écrit : > > ...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"... > > Releasing 2.2 soon would allow us to stop keeping the 2.1 branch in > sync, which is a pain IMHO. > > 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? > > 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. -- Peter Hunsberger