Wolf CMS development strategy
As the next release of Wolf CMS is approaching and we are planning to create a release candidate soon, I thought it was time to explain the new development strategy we will be following as a project after the next release.
There are many styles of development in this world and so far, Wolf CMS has been using an “its done when its done” approach.
Starting with the next stable release of Wolf CMS, we will be adopting a so-called ‘rolling release’ system.
For those of you who are not familiar with this system, this will mean that the latest and greatest version of our ‘master’ branch in the git source code repository will also be the latest stable version at all times.
As soon as a feature has been tested and deemed stable enough for production use, it will be merged into the ‘master’ branch.
The same will apply to bugfixes. As soon as a bugfix has been tested and approved, it will be merged into the ‘master’ branch.
This new strategy will mean that features and bugfixes will become available much sooner that has been the case so far.
Git strategies and contributors
The development of Wolf CMS will continue to happen using git for source control. Details are listed below with the key rules that Wolf CMS will be following for its development on Github.
- The ‘master’ branch will maintain a stable branch policy
- All new features will always be merged through branches
- Each change of the code in the ‘master’ branch will also change the version number
- All Pull Requests must be made against the ‘staging’ branch, and no requests against the ‘master’ branch will be accepted
In essence this means that all contributors will have to send Pull Requests for the ‘staging’ branch in the future.
With this change in development strategy, Wolf CMS will also be changing its version numbers. At the moment Wolf CMS uses the classical version numbering scheme of major.minor.patch.
Starting with the new rolling releases, Wolf CMS version numbers will consist of only two parts: major and patch/build.
In essence, the major number is just a general indication of backwards compatibility. If the major version number changes, the most likely reason is either a huge change in the system or a change in the database layout.
The patch or build number will increase by one with every addition of a new feature or a bug fix in the ‘master’ branch.
For example, by comparing version number “8.121” with “8.125”, you know there have been four new features and / or bug fixes in the system.
For the complete details, please see the wiki page on version numbers.
In the next few days we will be doing some updates on the website with regards to documentation and the wiki.
Apart from that we’ll be completely focused on preparing for the first release candidate of what will be Wolf CMS 1.0 (previously 0.8.0) which will be the first release using the new version numbering scheme.
We will also be doing more posts on a variety of subjects. If you are interested in a particular topic, feel free to post your ideas / requests in the relevant forum topic.
— Martijn, founder and lead developer