On 2/25/06, David M Johnson <[EMAIL PROTECTED]> wrote: > I agree that's a problem with the milestone approach.
I'm not seeing the problem. Could someone explain it again in different terms? The only real difference is that instead of making a predetermination that a build will NOT be a release, but only a release candidate, we wait and make the determination after it is released. This simplifies the nomenclature and reduces the work of recasting the final release candidate as the final release. We just announce that a certain milestone is ready for primetime. As for things like database upgrade scripts, once a milestone runs, the scripts are frozen in the distribution, we can just rename the script for the next milestone. So the 2.0-2.1.4 script becomes the 2.0-2.1.5 script. And with SVN, we can actually rename the file! Teams like HTTPD, Tomcat, Struts, and MyFaces have been using this scheme for a long time, and it seems to work well. Once the 2.1.4 milestone is rolled, the nightly build becomes the 2.1.5-SNAPSHOT, so there is no ambiguity about what comes next. > And I definitely agree that we need a more systematic approach to > making releases. > > I don't have an answer, but maybe by sharing some information about > our development and deployment cycles we can find come common ground > here. > > How often do customers and contributors like Javalobby, IBM and > others want to deploy new features? With the milestone approach, people have the option. It's not uncommon for there to be several GA releases with in the same version series. If the changes to 2.1.5 are not compelling, they can wait until another milestone, and jump in at say, 2.1.12. Whether a milestone contains only bugfixes or includes new backwardly-compatible features is something people can decide in a release plan for each milestone. We've been using a checklist format for the Struts release plans, which seems to be working well. * http://wiki.apache.org/struts/StrutsRelease128 > At blogs.sun.com, we like to make changes in small, incremental, easy > to test and easy to document chunks. Allen and I make monthly > deployments like so: > a) Second to last Thursday of month - code freeze / deploy to > production > b) Last Thursday of month - deploy to production > > Monthly works well for us (except for large feautures like group > blogging), but I've never thought that monthly Apache Rollerser release > make sense because other contributors don't have time to test every > month and I doubt customers want to upgrade on a monthly basis (or > the alternative, which is to fall behind). Oh, people always fall behind. Struts has a 18-month release cycle, and we still have a lot of people who want to migrate from 1.0 to 1.2, or from 1.1 to 1.3, or from 1.0 to 1.3.The curse of distributing reliable high-quality software is that makes it easier for users to stay the course! The important thing is that we have a release process that suits our core customers: the Roller PMC. It's nice that other people use our software, and hopefully some of these people will become contributors and committers, but the people we need to please first are the frontline volunteers who make the software possible. -Ted.
