Decoupling SeaMonkey and Thunderbird Schedules

At the SeaMonkey and Thunderbird meetings this week, I started advocating for the SeaMonkey 2.0 schedule to be decoupled from Thunderbird 3.0, specifically, to have SeaMonkey 2.0 Beta 2 and final be released before their Thunderbird "counterparts".

For some fun around this, let's view a proposal of a schedule I sent to the SeaMonkey Council in mid-December 2008:
We actually did release Alpha 3 on March 3 and Beta 1 on July 21, and added a second beta that is still to be released, apart from the fact that Thunderbird plans changed significantly as well. I don't really know if I should laugh or cry when reading that proposal from 7-8 months ago.

So, what went wrong or not as expected? For one thing, there is this old rule that every project takes longer than expected, even if you plan with that circumstance in mind. For the other, we decided to follow Thunderbird schedules so that freezes for the shared mailnews code code are aligned and we cause each other as few problems as possible. And that turned out to be the wrong thing to do for the SeaMonkey project, because the objectives the two projects have for the upcoming release series are quite different and therefore impose different scheduling.

Thunderbird has a new team that took over after a period where development stalled, and they try to show off that things are moving as well as make the product better fit for the mass-market.
SeaMonkey has the team that has been in charge for some years now, where it did continuous development, and we try to get our existing userbase to a new level while making the product more compelling to the same target audience as before

Thunderbird's current stable release is built on top of the "new toolkit" platform also used by Firefox, including good add-on management, mail and news standards haven't seen significant new features, and their security updates are driven by MoCo on well-managed, redundant release infrastructure.
SeaMonkey's current stable release is built on top of the "old xpfe" platform inherited from Mozilla Suite, with quite bad add-on management, the web sees lots of new developments in standards, and I need to manage our security updates myself, building them on my private machines that definitely show their age and have zero redundancy.

On top of that, Thunderbird has multiple people working full-time on the project, so that they are able to hand off management of releases where needed and have some organizational redundancy while in SeaMonkey land I'm the only one working full-time on the project and doing all release management and build engineering work without real redundancy.

And then, I have booked the flight for a three-week vacation in November, believing this to be far from any release. There I need to get off my thoughts from day-to-day work, have enough breathing room to really have some fun and appreciate the beauty down in Dixie so that I can "recharge my batteries", figuratively speaking. The last thing on my mind there is a major release that still need to be completed even though it should have been out for half a year.
I don't think I'd manage to really relax with an unreleased 2.0 on my mind, and that would probably leave lasting damage to my mental health, which I would like to prevent.

Given all that, I convinced the team at the SeaMonkey Status Meeting to target a freeze for Beta 2 on September 1 and assure that we will release final before November. We will re-evaluate the target freeze date in the next meeting on August 11 and make firm schedules there - but remember that a code freeze for that last beta also means a feature freeze for the whole 2.0 series!

This might mean that we possibly won't get everything into 2.0 that we would have liked to have there, but we are in no way short of total improvements in this series, and it's time we get something better than 1.1.x out to our regular users. There will be further releases, hopefully with smaller steps, following the "release early, release often" methaphor that's proven to be successful in open source projects overall.

I would have liked to sync up with Thunderbird as freezing shared code at different times can be somewhat painful at times, but given the different objectives, they seem to be less pressed by time and more pressed by features, while we already have a big load of features to show off in this release, but are overdue to deliver something.

I hope things work out fine that way and I'll blog again when we know even more on concrete schedules.