1

In creating a package with Data Types and Items, what are the best practices to follow for subsequently upgrading a package in order to retain the data that's created on the site while adding a change to the associated Type?

Should the package name remain the same or should it include version information to retain uniqueness by version? The version number of the package does not seem to enforce any type of upgrade policies.

Currently during development the package is uninstalled then the newer package is subsequently installed however after the package reaches production I believe this type of upgrade workflow will not be sufficient without affecting the associated data.

skaffman
  • 398,947
  • 96
  • 818
  • 769
Kevin
  • 45
  • 4

1 Answers1

0

As long as you increase the package-version but keep its unique GUID and Name, you're able to install the same package again, forcing C1 to overwrite the existing files, configuration etc.

This has a few caveats though, mainly if you need to delete some old files or configuration entries during installation, since that's what you normally do during un-installation. But you can still do it, writing your own installaton-steps code.

It is classes inheriting from some core base package-classes that you can invoke during installation. It can contain logic like checking if certain other packages are installed, do custom special logic, or clean up from earlier upgrades.

But yeah, long story short, as long as the version number increases you can "upgrade" a package, by installing the newer version, while the older one is still installed.

Community
  • 1
  • 1
Pauli Østerø
  • 6,878
  • 2
  • 31
  • 48