At the moment we're facing upgrade difficulties that aren't entirely off our own making.
In particular OpenACS 5.0 requires some PG 7.3 features, but upgrading from PG 7.2->PG 7.3 introduces complexities which aren't, strictly speaking, "our problem". Yet ... we need to support this upgrade path.
Even after this upgrade, there's constraint metadata in PG 7.3 that's missing in PG 7.2, which means in the future we can't necessarily rely on being able to do ALTER TABLE on an instance that's been migrated from PG 7.2->PG 7.3. It may be possible to write an upgrade script to drop all referential integrity triggers (FOREIGN KEY constraints) and recreate them with ALTER TABLE but that won't happen for 5.0 and will never be automated (you'd only run such a script on an instance you know was migrated from PG 7.2->7.3)
And Dirk Gomez reports that migrating from 8.1.7->9i requires FORTY-THREE manual steps! (he is going to investigate whether or not an export/import cycle will suffice but since Oracle documents the manual steps, it may not).
Fortunately thus far the AOLserver and Tcl people have been kind enough not to f**k our world in such fashion ...
Anyway ... we need to address upgrade problems due to changes in our underlying platform as well as upgrade problems we bring upon ourselves, and our criteria probably needs to expose the fact that we run into such problems.
