My 2 cents with obligatory dogma.
Monthly release cycles are too short for us.
I can see us doing short release cycles only with some additional
investment in the following areas.
(1) Much much better test automation and coverage, including the upgrade
path. New code => new tests with good coverage.
(2) Strict non-breakage policies on the trunk. Successful build = full
test passage.
(3) Establishing a practice of developing new features very completely
on branches, followed by an integration/test cycle wholly on the branch
before integration back to the trunk. Branch development could span
multiple release cycles on the trunk.
One can argue these are healthy directions to push in anyway (I would
certainly support that), but the fact is we're not nearly good enough at
these now to make a jump to short release cycles right away.
--a.
Matthew P. Schmidt wrote:
Hi guys. I don't have any voting rights in Apache, but I do run the
largest public installation of Roller (to my knowledge), so I figued
I'd chime in. While I'm a strong believer in release early, release
often (we do it at JL all the time), when there are others using your
application who have to upgrade/migrate, it isn't always the best
choice. We all know that upgrades never go as smoothly as planned,
even with the best designed software, and when things require database
changes, it gets even worse. It seems to me that you'll be leaving
out a large group of users by not making bug fixes to old releases and
by forcing them to deploy new versions every month if they want to
stay with the supported and stable release.
I also have to agree with the problems listed for monthly
deployments. That's a pretty short lifecycle to be developing new
features, testing them, and deploying them. At that pace you'd almost
have 1.1 and 2.0 back to back in a month (extreme I know, but could
have been possible).
Anyway, those are my thoughts, if I had a vote, I'd stick with
slightly longer release cycles.
Matthew P. Schmidt
Vice President of Technology
Javalobby.org
Email: [EMAIL PROTECTED]
Phone: 919.678.0300
Dave Johnson wrote:
My group (the blogs.sun.com or BSC team) at Sun believes pretty
strongly that small incremental releases are easier to document and
deploy than large ones. Following this philosophy, we deploy new
features to our sites on a monthly basis. This presents some
challenges for us because work directly with the Roller code-base
and we don't maintain a separate fork of Roller.
I had been thinking that BSC would deploy each month, operating off
of SVN HEAD, but the Roller project would make releases every couple
of months -- when new features justify a release. Each major
Roller release (e.g. 1.2) would happen in a branch and would get one
or more bug fixes releases (e.g. 1.2.1 and 1.2.2, etc.). I thought
monthly releases were too frequent. My reasoning was this:
* Nobody would want to track the monthly releases
* Users who don't track will have more difficult upgrades
* Users who have deployed existing releases expect bugs to be fixed
in those releases
* Users would want to stick with major releases for a long time
But there are problems with that. One problem is limited resources.
Since BSC folks (Allen and I) are busy making monthly deployments,
we have limited time to participate in the testing, documenting and
releasing of big every-couple-of-months releases. We also have
limited time (and limited interest) to work on fixing bugs in old
releases of Roller.
Long story short, the BSC team is now pushing for monthly Roller
releases to match the monthly BSC deployments. As a BSC team member,
I have to advocate this and that is what I'm doing by writing this
email. But as an independent Roller team member, I'm undecided. I'm
not sure how I'd vote, so please help me out with some lively
discussion.
So, let's say the Roller project makes monthly releases. What are
the implications?
* The SVN HEAD must be very near stable at all times because a new
release is never more than a month away. Any large development that
takes more than a month must occur in a separate branch (as we're
doing with Roller 2.0 / group blogging).
* It is no longer feasible to make bug fixes to old releases of
Roller. The way you get new bug fixes is by keeping current on Roller.
* To make it easy for users to keep up with Roller we'll need to
limit the frequency of database schema changes and when schema
changes do occur, the database upgrade must be automated and trouble
free.
The advantages of release early, release often are well known so I
won't cover them here. You can read what ESR has to say about the
philosophy here:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
ar01s04.html
So my questions are:
* How does the Roller community feel about monthly releases?
* Is there any Apache policy that is relevant to this discussion?
* How do we use the Apache voting rules to resolve this?
- Dave
