While migrating our test platform to a production server and our usual MySQL cluster, we have stumbled upon some bugs with the remote MySQL support (which is technically not part of the release objectives, but so trivial and expected that I'm putting extra work on it). I have also fixed up a bit the INSTALL.txt and can confirm that HEAD still works fine and installs properly with Drush's HEAD too.
Upgrades
Upgrades from 0.1 are a bit more tricky now, especially if you have a lot of sites on your platforms. The thing is that the database structure changed quite a lot between the releases, particularly on the way site packages are managed. This means that all sites and platforms need to be verified. Since we had a pretty wild development platform on 0.1, I can't really blame that on 0.2 or the upgrade process, but a lot of sites are broken (or at least not verified properly) after the upgrade. It also takes a long time to go through all those verifications. During the upgrade, some verification tasks were duplicated, which may explain some problems. Eventually, if you hit hard enough on those retry buttons, the sites eventually get verified properly (except of course those sites of yours which were already broken, which I suspect is the case with the many sites we have broken here).
Nevertheless, I have fixed up some nitpicking changes in the UPGRADE.txt file which you should all read before/while upgrading.
For the record, only 3 out of 32 sites on our dev environment haven't passed tests. One of those was already seriously broken by developpment tests. So for me, that's a pretty good score for a system that's not even at a 1.0 release and barely starting proper development of features as exciting as ... automated upgrades!
Migrating between servers
Also note that I have been able to manually migrate a site between two Aegir servers, something that will be automated in 0.3, but that you can already do for some reason. The basic process is this:
- on the old Aegir server, do a backup
- on the new server, create a platform identical to the one on the old server
- on the new server, create the site (it will be empty, but we'll change that soon)
- on the new server, do a backup of the empty site (this is to be able to restore something later)
- transfer the backup from the old server to the new server, copy over the backup in the new platform
- on the new server, restore that backup
You should probably run a verify task at this point to make sure everything is alright.
Note that this process is necessary only if the new server doesn't have access to the database server of the old one directly. If both servers have access to the same database (which wasn't our case), you could simply just transfer the whole platform directory (ie. the Drupal directory) and add a platform node pointing to this directory. This will trigger a platform verification and site imports and then you will be able to migrate those site in whatever platform you want.
Kudos
At this point, I need to say a big Kudos to the Drush team for letting us merge in so much of our code in the project and reorient the architecture this way. The drush/aegir combo feels much more "sound" than before and the whole thing seems much more stable than in 0.1, especially considering we're still in alpha. I have yet to find release critical bugs that we haven't fixed within 24h...
I think we would be ready to put out another alpha (a beta, even?), especially since I heard Drush is quickly heading for a more stable release shortly.