There are several different methodologies on software versioning and the AppThemes team uses the popular method, Semantic Versioning (aka sequence-based) which we’ll explain below.
This makes it much easier to isolate issues when trying to debug with your customers. It will also allow them to automatically upgrade via the AppThemes Updater plugin.
Each product release is assigned a unique identifier that consists of one or more sequences of numbers. Given a version number
MAJOR.MINOR.PATCH, these are the increment definitions.
- Major Version – Significant changes in functionality such as new major features, redesign, framework, etc which could cause incompatibility with previous versions.
- Minor Version – New minor features or significant fixes have been added that is version backwards-compatible.
- Patch Version – Major and/or minor bugs are fixed that were typically caused by the previous MINOR or MAJOR version.
Here are a couple examples as to how we’d release new product versions.
- Major release – ClassiPress 1.0.0, Vantage 3.0.0
- Minor release – ClassiPress 1.1.0, Vantage 3.1.0
- Patch release – ClassiPress 1.1.1, Vantage 3.1.1
The biggest degree of separation for a release is a major release versus a minor release.
A minor release is generally small in the scope of code it changes. Minor releases should not include any changes that require action on the part of the customer. Generally this means bug fixes or small enhancements. This limitation allows us to publish minor releases frequently because they can be applied without other code modifications.
A major release contains everything else. Feature changes, breaking changes to the API, and any other changes that require action on behalf of the customer. While we attempt to make upgrades as painless as possible, major releases allow developers the flexibility to require change on the part of the customer to further the product’s code base.
Other Release Types
Alpha software is very unstable and/or lacks major features. For example, right after releasing Vantage 1.2, the version should be bumped to
Beta software should be stable enough for internal testing. It does not need to be feature complete. There can be several (internal) beta releases:
Files generated prior to releasing beta to the public
- Vantage 1.3-beta0.1
- Vantage 1.3-beta0.2
Files generated for releasing beta to the public and after
- Vantage 1.3-beta1
- Vantage 1.3-beta2
Pre-beta release includes preparing files for internal review, internal testing, Marketplace Seller access prior to beta and more.
We strongly encourage the use of a cloud-based version control solution. We use Github but BitBucket is fine too.