I did two major releases over this weekend. The big cygwin switch from perl 5.10 to 5.14 (~1 year work) and the next supported ("stable") parrot release 4.6.0 (exactly 1 month work). This deserves a blog post to compare the two efforts.

The cygwin perl packages are using self-written bash scripts to automate the build and release process. They support also self-compiled variants with different features (debugging, non-threaded, different cflags, Policy.sh, ...) and those perl's can be used in parallel to the officially supported one.

It should also be noted that perl in cygwin does not package every single perl module out there, it rather leaves the installation and dependency game to CPAN or cpanm. Official cygwin packages depending on certain perl modules can just use a cygport three-liner to create this package and install it into vendor_perl. cpan installation go into site_perl. debian and fedora e.g. package every single module into their own package format.

The next important information is that cygwin is awfully slow compared to a unix. A typical build needs a few hours to complete. On a unix system it needs ~20 minutes. I can compare numbers because I ran it on the same machine in different VMs. And my windows VM is even faster than my native Windows machines.

The cygwin release process is pretty easy for me. I maintain a lot of cygwin packages, so I have direct ssh access to the master machine on sourceware.org. Others have to write an email to the dev list and request an upload from a public url and some instructions for the release process. (test or normal release, which packages to delete or keep, ...).

You prepare at minimum two tar.bz2 files for binary and source, and a setup.hint file for the central installer database, for each package. perl itself includes perl, perl_vendor, perl_manpages and perl_debuginfo, and for a major release you also have to coordinate updates for all XS modules. About 120 cygwin packages depend on perl, so it would be good to test all of them with your new major release, and about 10 packages needs rebuilding because they are using XS modules in vendor_perl. That's much less work for a release manager than on debian or fedora or macports, because cygwin lets CPAN and the user do most of the work.

So for the 5.14 switch there were 5 people involved who used my test build I prepared in April after about one year work to get it right (and several months waiting time because of my cross-atlantic move and several mainboards burned in texan storms - worse infrastructure here than in India), uploaded their test versions, and than I complete the rest and switched all the packages on one go from old to new. This was a pretty intense release process.

Compare that to parrot

My release was a three-month cycled so-called "supported" release, which most packagers take. A minor major release. There were two potential difficult branches to be merged, io_cleanup1 and threads. Both seemed pretty stable, but small hairy details and lots of testing prevented both of them being merged, so the diff from my release to the previous was super short. You can call it stable because almost nothing changed. Good for me.

The next big improvement for parrot over cygwin is the amount of written release docs and automated release tools. But testing needs much more time on parrot. I tested it with all three branches (master, io_cleanup1 and threads) on debian, cygwin, solaris, openbsd and because threads were supposed to be broken on netbsd, solaris cc64 and darwin/ppc I installed a qemu instance of debian/powerpc which could not reproduce the blocking darwin/ppc errors, so threads could not be merged. Very sad.

But I least I wrote a blog post how easy it is to install various architectures with qemu. I'll make the ready images available for others to test. It will have various perls, parrot, and rakudo installed, so you can test your XS modules on uncommon architectures like powerpc, sparc and sparc64 pretty easily.

The actual parrot release needs two days. On the first day you cut the release, which is pretty much automated by several tools and test it on your various architectures. MSWin32 and cygwin had some issues, but none of them were regressions. And you test against the various users (=languages) of parrot, mainly rakudo and report any problems to them. This is very easy and smooth via irc. Be sure to test against installed versions of parrot also, because that what the pooor user will do. Developers live in their git repo and rarely install, but outsiders who might want to try it out use the official locations.

It should also be noted that the parrot build process is easily disturbed by an installed parrot. And working with git can lead to unexpected side-effects, like unclean repos.

On the second day, the release will be committed, the docs need to be updated on myriads of sites and the various announcements have to be done. Wait with the announcement until everything else is ready. Your fellow devs need to wait from the "bugday" (Saturday) until the release (Thursday) not to disturb the timeline of master. In theory no problem to let committers continue their work, because you have your own clean repo, and can cp (=cherry-pick) commits to master in this period. But then you'll have to rebase origin/master which is always a bad idea.