Forum OpenACS Development: Re: Upgrade and install management

Collapse
Posted by Dave Bauer on
Shouldn't this be fixed by testing your upgrade scripts?

That is, we shouldn't be checking in and releasing upgrades that don't work.

What does "all of them" refer to in this statement?
e) If the after_upgrade callbacks fail, the package is still enabled. This is okay in that it describes correctly what the callback does and when it is executed. Sadly the granularity fails here, so if you upgrade from XoWIKI 0.48 to 0.60, all of them will be executed after 0.60 has been enabled, which might not be the case as the enabling requires the after_upgrade callbacks to be successful.

I'll come back later and read your suggestions, I think most of them make sense, but I still think if any of the upgrades fail, your system is in an indeterminate state and you need to fix the problem, and go all the way back to your backup and start over. There's no way the system can recover from a partial upgrade.

You are ALWAYS supposed to backup before doing an upgrade. If you don't we can't be responsible. Its clear that especially if you have any custom code, you need to be careful with upgrades since its impossible to predict what will happen if you run an upgrade with a modified system.

So even if you don't have a "staging" server you should be backing up your system, making it unavaialable for login (I usually start it up on a different port) then run the upgrades, and then make the system available again.