Ted Husted wrote:
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.
this sounds much more complicated to me. i prefer the RC approach that
we are using now.
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
again, sounds overly complicated to me. i think our current release
conventions are fine.
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.
i think we should release as fast as the developers are willing and able
to. this may sound a bit bastardly, but who cares if customers don't
want to keep up with our release pace? that's their problem, not ours.
as Dave said, at Sun we are doing monthly releases and I believe we are
delivering enough code in each month to warrant a new release. we also
test each release on blogs.sun.com before calling for a Roller release,
so i think that is plenty of "production" testing. i don't see any
reason not to do a Roller release each month if we are delivering
valuable new code which is production tested. As Ted said, we should be
working to meet the needs of our frontline customers and I believe that
means blogs.sun.com followed by IBM, jRoller, and on.
speaking more generally, i think the longer the development cycle the
harder we make things on ourselves, so i have always advocated for short
and compact release cycles. also note that short doesn't mean short
time, it means short on code. if we are delivering valuable and well
tested code every 2 weeks then lets release every 2 weeks, if it's once
a month then lets release once a month, and if its once every 2-3 months
then we should release then. so to make my point as blatenly obvious
and repetative as possible, i think we should be doing releases based on
how often we are delivering valuable new code that has been properly
tested. IMO we are doing that once a month, so i vote for monthly releases.
-- Allen
-Ted.
