I’d like to give you guys another update of how our release process is going, especially since Thunderbird 3.0 is now released and we are not ready yet. To take the interesting details up front, I believe we will be able to release rc1 before Christmas. If no urgent issues show up, we will be able to release the 1.0b1 final for or shortly after Christmas. This release will be compatible with Thunderbird 3.0.
From the product point of view, we are ready. We have all the patches in that we think should belong in 1.0b1rc1. Therefore, the nightly builds should be of the same quality that the release candidate 1 will be.
If you cannot do without Thunderbird 3 and are brave enough to try pre-release grade builds, I’d suggest to take a look at our nightly builds. Be sure to do backups first though! Otherwise please bear with us until we have the beta released and stay with Thunderbird 2 in the meanwhile.
From the release engineering point of view, we are constantly running into Problems. I believe the biggest and most unsolvable problem is that I am in a different timezone than Mozilla Messaging’s release engineering, which means there is only a small timeframe where we can communicate about build issues. All other problems are at least solvable, but need some time to identify and find a solution for. Each attempt for building the release candidate has a build number. Let me summarize what happened during our builds:
- Various problems before we could start building, including but not limited to missing access and l10n problems.
- Build system problems caused first mac/win32 to fail, then linux/mac to fail, and so on. The reason was that a script only used for calendar was called with the wrong path, but only in the rare case that the build is called with the packaging target needed for the release.
- We noticed, that Thunderbird 3.0 has some storage changes that are not on the normal 1.9.1 branches, so we needed to make sure the calendar release branch is based off of the Thunderbird 3.0 release branch.
- Lightning version number was incorrect, the version bump script doesn’t take care of install.rdf changes
- Mac’s lightning.xpi is not universal, which means we need to respin. Also checked in some last minute caldav and wcap patches we probably would have taken for rc2 anyway.
- Normal Sunbird builds succeeded, localization repack failed. I hope gozer knows why this is happening and can tell us tomorrow.
Another “problem” is that gozer needs to trigger and upload the Lightning builds manually, which also takes extra time once for each build. I do hope we can finish off the last problems soon. I’d like to again note that next time around this process will be much shorter. We don’t need to fix the small build system issues, all we need to do is update the release config and trigger a build.