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.

Overview

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.

Version Examples

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

Further Details

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

Alpha software is very unstable and/or lacks major features. For example, right after releasing Vantage 1.2, the version should be bumped to 1.3-alpha.

Beta

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.