Elastic Path Commerce for AWS Setup
Core Commerce Architecture
Cortex API Architecture
Tutorials & Code Examples
Elastic Path Production Tools
Core Commerce Release Notes
Cortex API Front-End Documentation
EP for Adobe Marketing Cloud Architecture
EP for AMC Developer Documentation
EP for AMC Release Notes
Cortex Studio
Version Number Conventions
Version Number Conventions
The following conventions are recommended for versioning customer projects:
Best practices
Do not reversion development branch on each release
- Updating the development branch version number on each release is additional work, adds noise to the commit history, and provides marginal value.
- It is more effective to update version number only on release branches and to use the same development version throughout the project.
Update versions numbers only on the release branch
- Update versions numbers on the release branch immediately after it is created. This will distinguish release artifacts from development artifacts.
- Do not merge version number changes back into development.
Recommended versions for release branch
It is possible to release using either SNAPSHOT or release versions. It is easier to use SNAPSHOT versions, but this may not be acceptable for all clients.
| Project | Convention | Maven Examples | OSGi Examples |
|---|---|---|---|
| Extensions | <extensionMajorVersion>.<extensionMinorVersion>.[<extensionBuild>] | 1.0.1 1.0.1-SNAPSHOT | 1.0.1 1.0.1-qualifier |
| Core Commerce & Commerce Manager | <productMajorVersion><productMinorVersion>.<productBuildNumber>.<extensionVersionRepresentation> | 700.1.101 700.1.101-SNAPSHOT | 700.1.101 700.1.101-qualifier |
Note:
Project teams may adopt variations on the above scheme for versioning extension projects. The key principal is that the <extensionVersionRepresentation> element should clearly represent the extension project version.
The normal practice is to reversion the Core Commerce and Commerce Manager whenever the Extension project is reversioned. The versioning scheme should make it easy to correlate these project versions.Note:
The rationale behind the product versioning convention is:
- OSGi restricts us to a maximum of three numeric version elements, plus a suffix. Note that SNAPSHOT versions have a suffix of .qualifier
- The first two version elements are reserved for product use to identify the product version and build.
- The final element is available for customer projects.