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

Reply via email to