- Update: It is the installation of a higher version of the module within the same major version as the currently installed in the instance.
- Upgrade: It is the installation of a higher version of the module within a higher major version than the currently installed in the instance.
Currently there are two modules that require this feature: core and Advanced Receivables and Payables. Both of them will have 2 major versions.
0. Upgrade is not supported in old ERP versions (<=2.50MP21?)
0.1 Scan for updates
When scanning for updates, upgrade is not presented even it is compatible with the currently installed modules.
Ideally a warning message should be shown telling there is an upgrade available but update to >2.50MP21 is needed to be applied before. The problem is currently, in case CR returns the instance in consistent with the modules to update, no message is shown, if it returns it is not consistent, the messages is shown as error but the process is stopped.
0.2 New module installation
Taking into account the two modules that will initially be defined as not default upgrade. Core cannot be installed (it is already installed), ARP 1.x will depend on core 2.50.x, ARP 2.x will depend on core 3.0.x. So when trying to install ARP (latest version) from a 2.50 instance, ARP 1.x will be installed and a warning message will be shown.
Problem is that this message is generated in ERP, so it cannot mention it is needed to upgrade to 3.0.
1. CR Upgrade Support
1.1 Modules define upgrade capability
A new default upgrade boolean field is added to AD_Module.
When this property is true (default value), upgrades are not distinguished from updates, so it behaves in the same way currently does.
If it is false, only updates are proposed by default, upgrades are managed in a different way (new behavior).
1.2 CR distinguish upgradeable modules
Taking into account default upgrade property, when scanning for updates not default upgrade modules would:
- Propose updates in the same way as currently is done.
- Additionally propose upgrades for the module.
1.3 Upgradeable capability is overwritable
Default upgrade property can be overwritten in ERP instance from Settings tab in Module Management window.
2. ERP UI
2.1 Distinguish upgrades
For not default upgrade modules, show differently upgrades if they are available.
2.2 Show not applicable updates
For all modules, in case there is an update that is not applicable in the instance due to not satisfied dependencies, display it.
3. Disabling modules
- Disabling modules physically removes code and metadata information from DB.
- Modules that participate in dependencies for other modules cannot be disabled unless their parent modules are also disabled.
- Once a module is disable it is not send to CR as installed, so it does not participate in consistency check and updates/upgrades are not proposed for it.
- A local check consistency is performed before enabling modules.
4. Enforced upgrade/update
4.1 Show modules to disable
Together with requirement 2.2, the modules that prevent the update are shown so user can decide to disable them to be possible to apply the update.
4.2 Automatically disable
Optionally, it is possible to install not applicable modules automatically disabling all modules that prevent it.
5. Extend module dependencies
Add to CR capability of extending defined dependencies for a concrete version. When dependencies are extended a new version is automatically created and published.
By now this capability will be available only to central repository admins.
It is allowed to define less restrictive dependencies but not in the other way around, other case it could happen that an installed version within a consistent instance to become inconsistent.
Allowed changes are:
- User enforcement: No -> Yes
- Enforcement type: Minor -> Major -> None
- From version: A lower minor version in the same major version (does this makes sense?).
- To version: Depending on enforcement type:
- null->a higher version than from (major or minor)
- not null-> a higher version than the originally defined
- null->a higher major version than from
- not null-> a higher version than the originally defined
Additionally it would be useful to present latest version of the dependency (and maturity status).
6. Support upgrade from 2.50
The capability of hiding modules to install/update that depend on 3.0 but not on 2.50 in older versions, will be implemented by adding the Repository concept.
Module versions can be associated with repositories. When searching for modules to install or when doing check consistency, only versions in the subscribed repositories will be found.
By now there will be two different repositories 2.50 and 3.0. When publishing new versions the process will automatically set the correct repositories to the version. In case it depends only in 2.50, repository 2.50. In case it depends only in 3.0, repository 3.0. If it depends in both, both repositories. Note that dependency on core can be indirectly done through other dependencies.
When performing search or scan actions, old erp instance will only subscribe to 2.50 repository, so all versions in repository 3.0 will not be shown.
In future this capability could be extended by adding new repositories and being possible to explicitly subscribe from erp. In this way it could be possible not to show versions in different repositories (example private repositories...)
Open discussion items
Closed discussion items
- ALO: Default upgrade property should be added in AD_Module or in CR?
- ALO/ICI: To be added only to CR.
- ALO: Which upgrades should be shown: latest available or latest compatible? For example, there is 3.0.1 and 3.0.2, being 3.0.1 compatible with the modules within the instance but 3.0.2 not. In this case I would propose 3.0.1, and after installing 3.0.2 would be shown as non installable preventing in this way disabling modules.
- ALO/ICI: Latest compatible, and after installing it latests.
- ALO: In case multiple upgrades of different major versions are available, should all of them be proposed or just the latest one?
- ALO/ICI: Just latests.
- ALO: Should upgrades/updates for disabled modules be proposed? If so, when installing them, only DB tables for this modules should be updated. If not how should be the enabling flow in case the disabled version is not compatible with the instance anymore but there are updates that would make it compatible?
- ALO/ICI: They should be proposed, but when installing them, no updates to DB are executed. They do not participate in check consistency but latest version is always sent, so it is possible to maintain it.
- ALO: Is requirement 1.3 needed. I think it would be rarely used, and I'm not sure if this capability is worth.
- ALO/ICI: Nice to have, not to be implemented now
- ALO: Should requirement 4.2 implemented?
- ALO/ICI: Nice to have, might be implemented because it should not add much overhead.