Noel J. Bergman wrote:
It seems odd to me that code changes effectively require consensus, but a release would not. What am I missing here?
All code in CVS is already there on consensus.
As are the bugs ;-)
Seriously, this seems like sort of a grey area between "technical, code-related" (so needing consensus) and "policy." The decision to cut a release has technical implications (e.g. backward compatability), but it is not a technical decision per se. I am not pushing for this, just trying to understand better how we look at releases.
There are two schools.
For Struts 0.5, 1.0 , 1.1 we used the criteria that all bugs had to fixed or marked as later.
As a result between 0.5 and 1.0 took 12 months
and between 1.0 and 1.1 took 20 months.
For Struts 1.2 we agreed to switch to the x.y.z
style that Apache HTTPD and Tomcat are using, where you post the bits and
then call for a vote on stability (alpha/beta/general availability).
A release can also be withdrawn.
After a release there is often a flood of new users, and a few, usually very few new bug reported.
More importantly there are improvements new users make and hopefully share
as they tinker with and extend Struts to make it fit their needs. It's this synergy that is good for the project.
We tried it the other way first and while we were always making progress on the software,
the development could have easily stagnated. Between Struts 1.0 and 1.1 we were fortunate enough
to vote in about 8 committers, each gave the software development a much needed boost.
By releasing more often we hope to actually increase the quality, by the fact of greater participation
from the app developers. It's easier to do this now in Struts since presently it is in an evolutionary mode.
Also I would say that Tomcat and HTTPD are two of the most successful projects Apache has
so they have to be doing something right.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
