New Classes for WBCE CMS,  1.4.1
Documentation for all new Classes in WBCE CMS
WBCE CMS Semantic Versioning (Version 1.0.0-rc.1)

WBCE uses Semantic Versioning (http://semver.org) called SemVer in the following text. For core development using SemVer is mandatory for modules development this is recommended.

Specification and Options

Clarification

The current version number is defined at first alpha release according to the guidelines of SemVer. We have the options for bugfix, minor or major release. After this initial pre-release only the pre-release tags are increased until we reach the actual stable release. Usually this first pre-release comes with a feature freeze in development of this branch.

In case it is necessary to do new major or minor changes while already in the process of pre-Release. It is possible(maybe even necessary) to increase the the version number to comply to the rules of SemVer. For example we at version 1.1.3-beta.4 but it becomes necessary to add more functionality to fix a special problem that otherwise could not be fixed. Then it is possible to move version to 1.2.0 immediately. The new pre-release status of this version may or may not have changed(alpha<->beta<->rc) depending on what the change achieved. But in any case we start again with .1 (1.2.0-alpha.1, 1.2.0-beta.1, 1.2.0-rc.1). Doing this should be avoided if possible and only be applied it there a drastic changes in the user experience or module management.

WBCE_VERSION, WBCE_TAG(/admin/interface/version.php) and version tag on Github are all set to the same value defined by this Document.

Some Comments

Please keep in mind all those definitions allow a certain degree of interpretation so please don't be upset if do not understand a certain versioning decision made by our development team. We are always open to questions about the how and why.

As there is no existing API definition in WBCE CMS right now we only got the option to define the Codebase as API for versioning. All new classes and features hopefully should be documented well and so the problem will dissolve over time.

Recommendations

The function version_compare() from PHP fully supports this versioning scheme, so we recommend using this function.

Example

Recent version: 1.4.2

The recent Master has reached a level that makes it worth doing a first release.

First step should be to declare a feature freeze so no new features are added to this release.

This version had some bugfixes we also added some new Features. New features define a new minor release.

New release is Version: 1.5.0-alpha.1

Now the release goes through several test phases: 1.5.0-alpha.2, 1.5.0-alpha.3, 1.5.0-beta.1, 1.5.0-rc.1, 1.5.0-rc.2

After all it becomes a stable release: 1.5.0

A special case: We are at 1.5.0-beta.3

We soon realise that some functionality needs to be removed or otherwise its impossible realize certain changes. In this case we got the option (or maybe the responsibility) to move the version number to 2.0.0 . In this example we decide that the pre-release status stays beta. Resulting Version: 2.0.0-beta.1

Please keep in mind that this is a drastic action and increasing the version number while in a pre-release process and this should only be considered if there is a radical change in user experience or functionality.

After this the pre-release continues as usual: 2.0.0-beta.1, 2.0.0-rc.1, 2.0.0-rc.2 and finally 2.0.0


License

This document is released under Creative Commons License: Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) https://creativecommons.org/licenses/by-sa/3.0/

Authors: Norbert Heimsath (heimsath.org) Christian Sommer (cwsoft)