Package manager should have an upgrade framework

[isc-kiyer]

If a package is already installed and needs to be upgraded, the package should be able to indicate upgrade steps to be run between any source and target versions.
The package manager should have separate commands for upgrading a package vs fresh install with the ability to intentionally override and do a fresh install (bypassing upgrade steps) if they want (for example in a dev environment).

[isc-shuliu]

@isc-kiyer What are some of the differences to consider between upgrades and fresh new installs?

I can think of only 1 case where the package developer renames some classes and we need to migrate the associated data (like with %ZPM -> %IPM).

Are there any more things to look out for?

[isc-tleavitt]

@isc-shuliu the primary motivation is data migration/schema change steps, which don't necessarily correspond to a class rename. New indices would be another use case. Really, it's all around data.

HealthShare has some more specific use cases / constraints (along with plenty of examples) and I'd recommend that you and @isc-kiyer or @isc-eneil meet to discuss them.

[isc-shuliu]

@isc-tleavitt
After discussion with the HSOPS team, IPM will provide an abstract class for upgrades. Package developers are responsible for subclassing it to implement their own upgrade logic for every earlier version.

Each upgrade could contain many methods (tasks), even if just bumping up one version number, so that users can see which tasks are successful.

IPM will figure out the correct order to run the methods as part of the installation process. We still need to figure out which conventions to use. This GitHub issue page can be used for discussion.

[isc-shuliu]

Internal reference: HS.Util.Installer.Upgrade.Loader & HS.Util.Installer.Upgrade.ModuleAbstract