Comments below...
On Feb 25, 2006, at 12:20 AM, Henri Yandell wrote:
On 2/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 2/23/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
Personally, I think it gets silly to have to vote each time.
The danger of a bombastic statement; everyone includes that one line
in their replies and not the "however here's why we should" bit
afterwards :)
Well, we really shouldn't cast a binding vote on a release until we
put into production ourselves. ("Eat our own dog food.") Since
this is
a new roll, we have to unroll it, put it up, and run the binary
through its paces. just to be certain all the bits are there.
Biggest problem I find with that is that it means following tests
aren't possible.
If I migrated production from 2.0 to 2.1-rc1; my next install is
2.1-rc1 to 2.1-rc2 and not 2.0 to 2.1-rc2 at the database level. So I
just run a test server until the real one is released.
Dave, Elias and others work more at the bleeding edge; but that means
their production servers tend to be on 2.1-pre-rc1 and that migration
tends to kick off the release discussions. Unsure where Matt
(JavaLobby) fits in on things release-wise.
I agree that's a problem with the milestone approach.
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?
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 features like group
blogging), but I've never thought that monthly Apache Roller 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).
- Dave
