Forum OpenACS Improvement Proposals (TIPs): Re: TIP #35: (Proposed) Relax Two Milestone Criteria for OpenACS 5.0.0 Release Candidate

Correct me if I'm wrong but what we're talking about is whether or not to provide an automated hands-off upgrade for this release, or require some manual steps.  In either case there will be either scripts or detailed directions.

Originally Dave and I were going to collaborate as mentioned above, with my offering to hack the bootstrap installer to "fix" your installation so the sysadmin can log in and do the rest.  That's the primary issue here - if you install 5.0 on top of 4.6.3 you can't log in until an upgrade script is run, but can't run the upgrade script until you log in.

Or you run the script by hand ... then log in and move forward.

In our last OCT meeting I was questioning the wisdom of running this script automatically when rebooting after the files are upgraded ... among other things people may be less likely to fully backup before rebooting thinking they'll have to run the APM upgrades before any changes are made?  And if our boot upgrade fails you'd be stuck with an unbootable system perhaps which would really suck ...

So a combination of some manual steps followed by the traditional APM upgrade steps seems safer to me at the moment.

Any comments?

Are there other packages that don't have complete upgrade scripts?  We have diddled the way relsegs and groups are managed by the new UI pages slightly between beta and today (bug fix, really) but hopefully people haven't been upgrading their production systems to 5.0 beta expecting stability to be guaranteed?

Am I wrong about this?

I haven't checked to see if Lars provided upgrade scripts to create the new "admin" relseg in all existing subsites but if not we DO need to do that...

I interpret the milestone criterion to mean, there is an automated upgrade from any version back to 4.5, and it works by 1) updating some files on the hard drive, 2) clicking Upgrade in the APM. We do not quite meet this criterion in 4.6.3, because you usually have to upgrade the kernel first and restart and upgrade everything else in a second pass.

A looser interpretation would be, there exists a successfully tested process for upgrading which does not require manual, site-specific manipulation of the database. I think we're not here in 5.0.0 either because we have only one successful report of upgrade.

Would it be possible to have a script that checks, if the upgrade has been run for 5.0 and if not, display one page at http://<yourserver>/ stating you have to run the upgrade script and are advised to do and backup before the upgrade, and skipping the whole initialization of packages ?

Is this the only "manual" task that needs to be done?

In general I'm in favour of offering a manual upgrade script with documentation for the time beeing and just *aim* for an automatic upgrade in future releases.