View source | View content page | Page history | Printable version   

Projects:Upgrade-Update/Functional Documentation

Contents

Glossary

Functional Requirements

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

3 days

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:

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

5 days

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

5 days

4. Enforced upgrade/update

2 days

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:

Additionally it would be useful to present latest version of the dependency (and maturity status).

6. Support upgrade from 2.50

Technical Requirements

Repository

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

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Upgrade-Update/Functional_Documentation"

This page has been accessed 1,395 times. This page was last modified on 8 June 2012, at 05:31. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.