Release Policy

Release strategy

We apply a feature-based release strategy. We first decide on the features we want to deliver and then decide on the time window. In the opposite time-based strategy, a release is made on a regular basis (say every six months), and the features depend on the time constraints.

We have major releases every 6 to 12 months or 1-2 major releases per year. Major releases may include API changes and integration adjustments. Minor releases come every 1-2 months and are strictly backwards compatible.

Versioning

Current scheme

Until now, we've been following the versioning scheme in the form of GENERATION.MAJOR.MINOR.PATCH. Increments in.

• GENERATION brings major conceptual changes to the feature set. The changes might not be backward compatible.
• MAJOR brings major new features and bug fixes. The changes might not be backwards compatible.
• MINOR bring new features and bug fixes with full backward compatibility.
• PATCH bring only bug fixes with full backward compatibility.

The increments on the MAJOR component have not been continuous, i.e. we've had jumps from 7.2 to 7.5 mainly due to feature related reasons.

Future

With release 8.0, we plan to switch to MAJOR.INTERMEDIATE.MINOR scheme, where increments in:

• MAJOR brings major conceptual changes to the feature set. The changes are very likely not to be backwards compatible.
• INTERMEDIATE brings major new features and bug fixes. The changes might not be backwards compatible.
• MINOR bring new features and bugfixes with full backward compatibility

This matches better the popular http://semver.org/ versioning scheme. It also simplifies things (no more jumps) and allows us to follow our long-term continuous delivery strategy.