Light-weight, fast, simple and powerful!


These are guidelines intended for the Wolf CMS core team on what release numbers mean and how to create a release.

This document currently contains two main things:

  • Version numbering scheme
  • How to create a release

Version numbering scheme

Similar to most Open Source projects, this project uses a numbering scheme. The numbering scheme that's discussed here is valid starting with the 8.0 release of Wolf CMS. (Version 0.8.0 under the old scheme)

Starting with the rolling releases, Wolf CMS version numbers have consisted of only two parts: major and build.

Syntax: Major.Build


  • Major = 0..N
  • Build = 0..N, resetting to 0 whenever Major number increases.

So, as you can see, the build number will increase by one with every addition of a new feature or a bug fix in the 'master' branch.

The 'build' number will reset to zero every time there is a major version number change.

For example, by comparing version number “8.121” with “8.125”, you know there have been four changed in the system for major version 8.

The major number is, in essence, just an indication of backwards compatibility. Every time a change is made to the system that is not backwards compatible, we increase the major number. In essence we would be saying…

“Watch out, this is a change that will require a DB backup and possibly manual intervention!”

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 which will mean the system is not backwards compatible. (In other words, you can't simply replace the files.)

So to recap:

If you have version 8.0, the first change in 'master' would turn it into 8.1, then 2, … 10, 11, and so on.

As soon as there is a change that's most likely not backwards compatible, the version number would change to 9.0 and continue from there to become 9.1, 9.2 and so on.

About Security Bulletins

Since we have rolling releases, Security Patches as we had them in the old system, are no longer needed. You simply upgrade to the latest version from the project repository's 'master' branch. GitHub already provides download links for the 'master' branch.

We will however provide Security Bulletins. These will in essence be warning or advisory bulletins that tell you to upgrade and why.

How to release a new version

  • Make sure the changelog.txt file is up-to-date
  • Make sure all components are checked into the repository
  • For major versions, create an tag similar to the examples below: v8
  • Update the downloads page on the site if needed
  • Test to see if the link to the files are correct (i.e. downloadable)
  • Write a blog post about the release
  • Write an entry in the forum pointing to the blog post for more details.
  • Update the version number in the “version” page of the site.
  • If applicable, also update the plugin-versions page on the site with any new plugin version numbers or plugins.
projects/release_related_guidelines.txt · Last modified: 2012-03-09 11:53 by mvdkleijn
Except where otherwise noted, content on this wiki is licensed under the following license:GNU Free Documentation License 1.2
Copyright 2010 / design by yello studio / Wolf CMS Inside