Yesterday, I finally could upload SeaMonkey 2.0 Alpha 1 candidate build 1 for (smoke)testing by our community QA people.
For me, this has been a complete new experience. All previous (1.x) SeaMonkey releases have been done on my private tinderbox machines, were cvs- and xpfe-based, had no crash reporting or automatic update support - things that all changed now. 2.0 Alpha 1 was created on Mozilla-hosted build machines, is hg- and toolkit-based, has a working open-source crash reporting system that needs build symbols uploaded, has has support for automated updates to later releases. That's the bright side.
The dark side is that I have a half-automated process for doing 1.x release, but neither Mozilla nor I have any working automated process for hg-based releases yet.
For 1.x, I have a script that gives me list of commands for version updates and tagging that I only need to copy and watch the output for doing stuff properly, and I just could copy the tinderbox configs, modify them to run only once and do a clobber and full rebuild, pull the release tag and upload to the candidate directory (the latter two are the only needed changes for every release), and then run those tinderbox client processes on the three machines (Linux, Mac, Windows). I even stuffed an additional script into the Linux config to create source tarballs and put them in the right place for being uploaded by tinderbox' upload step.
...
I hope we will not need another candidate build for this release (even though I learned a number of things I hopefully wouldn't run into a second time), and I hope the automated release process based on hg will be far enough so we can use it for Alpha 2 - but I finally understand the stories about Scotch whiskey being the best friend of release engineers...
By KaiRo |
