SeaMonkey:First Release

Resources
SeaMonkey Homepage
FAQ / Help
Goals
Organization
QA
Supporters
Add-ons
Localization
Reasons
Branding
Release History
Tasks & Projects
IRC Chat Logs
Discussion
Suiterunner

Ship happens. SeaMonkey 1.0 was released on January 30th, 2006.

SeaMonkey 1.0 release plan

SeaMonkey 1.0, the first release of our new project, is what a "Mozilla 1.8" application suite was meant to be. As such, it was released from the Gecko 1.8.0 base, which it shares with the Mozilla Firefox 1.5 and Thunderbird 1.5 releases.

We released an Alpha and a Beta release from the Mozilla 1.8.0 branch on the way to that 1.0 release:

• SeaMonkey 1.0 Alpha was released from Gecko 1.8b4, paralleling the Firefox and Thunderbird 1.5 Beta1 releases done by Mozilla Foundation. While the basic codebase may be more beta than alpha quality, our new release process is not completely settled, we don't have our final Artwork yet and we have no dedicated release machines in place, so it's better to call this an early testing release or "Alpha".
• SeaMonkey 1.0 Beta was released from Gecko 1.8, like the Firefox 1.5 release. This testing release also incorporated our new Logo Artwork for the first time. A sample userAgent/About string for it is Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b
• SeaMonkey 1.0 was shipped January 30th 2006 off the Gecko 1.8.0 branch, which might get a few security/stability fixes, but no big changes from what we shipped with beta. A sample userAgent/About string for it is Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

We have 1.0.2 nightly builds; please help us testing them!

The release processes are managed by the SeaMonkey Council, Chris Thomas is the release engineer in charge of that process.

The QA work needed for releases is overseen by our QA lead Andrew Schultz.

Release Checklist(s)

from n.p.m.seamonkey (written by bz):

> Without me knowing well what is involved in "pushing out a release"

At least:

1)  Tagging the trunk at some point when it's stable (coordinating this with
    other trunk Gecko/etc consumers, one hopes).
2)  Lots of organized and thorough testing of the branch you created.
3)  Filing bugs based on the results of that testing.
4)  Getting said bugs fixed on that branch.
5)  Writing release notes.
6)  Creating builds from the branch.
7)  Pushing those builds to the FTP server.
8)  Announcing the release.

Asa, please chime in if I missed something through ignorance?

I suspect step #2 is somewhat time-consuming, as are step #4 and step #5.

-Boris

Quoting Ben Goodger from IRC:

<ben_> so here's what you need to do to ship a release. 
       1. decide what you want out of it (a good start is to develop a product plan in 
          wiki.mozilla.org with checkmarked features/etc) 
       2. find engineers to do each of the items in the aforementioned list
       3. get those engineers to provide blurb+swag for each - this is a description of 
          the item + estimated time to completion or an ETA. 
       4. have them implement the features. 
       5. deal with bugs that arise, manage the
<ben_> 6. when your features are done, you can beta... when you get to a low level of 
       remaining bugs, you can kick off the final release process. 
<Callek> ben_ 5. Deal with bugs that arise, manage the  ...??? (cut off)
<ben_> the final release process involves things like documenting changes (release noets,
       product pages, etc). 
<ben_> er, "manage them using bugzilla flags, etc. prioritize them and have people 
       work on those."
<ben_> ... getting testing builds spun, having interested users test them and submit feedback, 
       driving the list to zero and handling new bugs as they come in.
<ben_> Asa probably has more info on the latter half of this process. 
<ben_> but what I would suggest starting with is saying, "what do we want from Seamonkey 1.8?" 
<ben_> and start listmaking in wiki.mozilla.org
<ben_> you need to identify the work involved in that task then
<ben_> break it down into pieces
<ben_> findpeople to help and get estimates.

MozillaReleaseChecklist

We'd really like to know what can be done by which people (perhaps some of those tasks can still be done or helped with by MoFo, but it seems we can't rely on that any more).

QA

Testrunner has testcases for the browser UI; the list should probably be extended to cover more functionality. It would be good to run at least basic tests regularly, to catch regressions early. Before the release, more extensive test runs should be performed.

Features

• Current Gecko - many improvements since Mozilla 1.7
• Ship a final release with the various UI improvements since Mozilla 1.7
• Port frontend for Bug 2920 (Delete attachment from mail message in folder) to MailNews
  • done
• Port Thunderbird's Inline Spell Checker frontend patch (Bug 278310) to MailNews
  • done
• Revisit the Autoscroll issue. (Bug 22775])
  • done
• Nice splash-screen
  • done
• Enable SVG and Cairo (Bug 294182)
  • done

For SeaMonkey 1.5:

• Enable calendar (Bug 182076)
  • The Calendar extension is no longer being developed, but the latest experimental nightly for Firefox 1.5 seems to work with SeaMonkey 1.0.x.
  • When SeaMonkey is ported to toolkit, it should work with the Lightning extension.
  • Sunbird is also available as a standalone calendar.
• Enable MNG again (Bug 18574)
  • this can only be done when the source is in mozilla.org tree, which hasn't happened yet
  • we will likely have contributed builds with MNG support from Alexander Opitz
• Port to toolkit (Bug 255807)
• Extension Manager (Bug 272429)
• Unattended install for corporate deployment (bug 268740)
• SPNEGO support (Bug 246861)
• Use 7-zip compression for builds (Bug 154965)
• Allow to easily migrate from/to Firefox/Thunderbird (Bug 63389)
• Port Thunderbird RSS/Atom reader to SeaMonkey (Bug 255834])
• Port Live Bookmarks to SeaMonkey (Bug 240393)
• Enable XForms (Bug 305395 )
• Improve the default theme (e.g. perhaps make Modern the default theme, see Bug 218329)
• Backout bug Bug 281402(or part of it) to re-enable Xprint under GTK2+ builds
  • biesi: can't xprint still be enabled? should be as simple as --enable-xprint, right?
  • ajschult: Yes. The biggest issue there is that Red Hat / Fedora no longer install libXp.so by default (bug 284444). It'd need to be dynamically loaded.
• Improve CSS rules for Message Grouping. Something like Bug 263255
• Disable IM button or add IM capability (Bug 214223 and Bug 218714)

...feel free to fill in more...

Talk about this