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
