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 development branch
| Project | Convention | Maven Example | OSGi Example |
|---|---|---|---|
| Extensions | 0-SNAPSHOT | 0-SNAPSHOT | 0.qualifier |
| Core Commerce & Commerce Manager Client | <productMajorVersion><productMinorVersion>.<productBuildNumber>.0-SNAPSHOT | 615.0.0-SNAPSHOT | 615.0.0.qualifier |
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 Client | <productMajorVersion><productMinorVersion>.<productBuildNumber>.<extensionVersionRepresentation> | 615.0.101 615.0.101-SNAPSHOT | 615.0.101 615.0.101-qualifier |
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 Client whenever the Extension project is reversioned. The versioning scheme should make it easy to correlate these project versions.
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.