Steven McCarty wrote:An upgrade should not break a working environment.
Quite right, if it's possible. FWIW Virtualbox is not the usual working environment. Imagine upgrading a PC's motherboard, and you forget the PC's OS was hibernated. Probably won't work well. That's quite similar to what a Virtualbox update is. It's not like Word or Photoshop, it's 'hardware' for a computer's OS.
Steven McCarty wrote:While a consumer is prompted to download and install the newest version, which is most excellent, the upgrade should detect known issues (like saved states), stop the upgrade, and inform the installer.
The only time such a warning could occur is when the user clicks the link in the Virtualbox message window to do the upgrade. (Is there a link? I can't remember, I turn the automatic update message off because I find it annoying and I don't upgrade until I need to. If it ain't broke, etc. Others turn it off too. I run upgrades directly from download links at
http://www.virtualbox.org) The installer and uninstaller are Microsoft MSI programs that are filled with Virtualbox data, not Virtualbox programs, so developer might not have as much control as this idea would require. Can an MSI installer or Uninstaller be programmed to find Virtualbox.xml (it does not have to be in the default location) then read it to find each guest on whatever drive it's stored on, then read all the .vbox'es to determine each guest's status?
Steven McCarty wrote:doesn't burn down their environments every time the developer makes a change
Cool thing about these environments is that they're recoverable if you change versions. Uninstall then put back the version you had before, and the saved-state guest can be started and shut down properly. Then redo the upgrade. Kind of a bummer that it takes extra work, but there might not be another way.
Feel free to suggest a change on the Bugtracker, though. We aren't the developers, just users.