On 2/6/07, Don Brown <[EMAIL PROTECTED]> wrote:
Alexandru Popescu wrote: > I see two clear stages: > > - a product that is ready from developers point of view > - a product that gets its users acceptance > > An OSS project can take the same approach or not, and this is up to > its management. However, I feel that a project that would like to be > widely used cannot be labeled as released version without the user > acceptance. > > I understand Don's concern about how these steps should be managed, > but I think this is not a very complex process: > > - developer's ready version: beta > - (after a scheduled period during which only fixes go in if > necessary): GA. I would love it if we actually did this. Unfortunately, we don't do the second step, which is to have a scheduled period that allows fixes to go in if necessary. What we actually do is freeze the code in a test build, and put that through an undetermined period after which it may be reassessed. If any problems are found after the build, the whole process starts again. What this results in is a project that very, very rarely releases a GA release because issues are always found after the test build. If you don't believe me, look how often we put GA releases out with Struts 1 and that was with a code base that rarely saw any significant development/features. Imagine how long it would take us to get out a release on a very active project...
That is definitely one of the lessons to be learned from the Struts 1.xexperience. Here's how we're applying that lesson in Shale land. The recent 1.0.4 release is the first one we felt had a snowball's chance at being voted GA quality, so as soon as we cut that release we also branched (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive bugfixes backported from the trunk) would be committed here. The trunk was then opened for further "new feature" development (as well as bugfixes). Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could easily become 2.0.0-SNAPSHOT if we wanted to do major non-backwards-compatible changes. The net effect is that Struts could: * Create a branch totally focused on stabilization and bugfixes ... the only *point* is to create a GA-quality branch based on the current feature set. If 2.0.5 does not cut the mustard, just fix the reported bugs and try again (weeks instead of years later). * Avoid slowing down new feature development ... it continues on the trunk. * If 2.05 (say) got voted GA but a security vulnerability or critical bug were later discovered, an updated version could be turned around VERY quickly on the branch. Just fix the bad problems and release it. You don't have to worry about stabilizing all the new features that might have been added on the trunk, because they won't be present on the branch. (The MyFaces folks are currently paying the same price we paid in 1.x, because they are intermixing new features and bugfixes on the trunk -- hopefully they will learn the same lesson.) Branches are our friends. The fact that we didn't leverage them is the biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the Struts 2 process can improve based on lessons learned from that experience. Don Craig
