Development of the core

Decision making

CMSimple_XH is an open source software developed by a free community, behind which no company or association stands. Therefore, there is neither a boss, nor anyone who has special authority to decide in which direction the software will develop. Instead, at least for all controversial changes, we have established a simple voting procedure, similar to PHP's RFCs and Python's PEPs, but a bit less formal. After a discussion on the forum or elsewhere, anyone is free to submit an issue to our Github repository to propose a change to the software. At the discretion of the release manager (version manager, this role is not clearly defined and can change), adding a voting label from time to time puts these proposals to a vote, which is also announced in the Open Development Forum. Voting is open for 18 days. Voting is done simply by adding appropriate reactions (usually thumbs up or thumbs down), but of course (preferably short) comments can also be added if needed. After the voting ends, the release manager will tally up the votes (though votes from unknown users can be ignored) and remove the voting label and replace it with to be implemented or close the ticket.

At least for less controversial changes, pull requests can also be submitted to our Github repository, and if no one objects, they can be merged after a while (at least a week) by anyone with commit rights. Trivial bug fixes can be committed immediately. In both cases, however, there should also be a corresponding issue so that we have a comprehensive and meaningful changelog. Correct refactorings (i.e., those that do not change behavior), typo fixes, etc., can be committed without a corresponding issue, as these are usually irrelevant to users.

Publication cycle

Starting with CMSimple_XH 1.7.0 the project follows semantic versioning. There is no fixed schedule, but typically revisions are released several times a year, providing only backward compatible bug fixes. In urgent cases, a revision may be released only a few days after the previous version. Minor releases, which may introduce new features and improvements and do not break backward compatibility (BC), are released a few times a year after there has been at least one release candidate (RC). Major releases, which may introduce incompatibilities with previous releases (BC break), are released at longer intervals. Major releases often have an extensive beta and RC phase.

Updates to new revisions and new minor releases should be kept as simple as uploading a patch, which usually does not overwrite any configuration, language, or stylesheets. Major releases, on the other hand, may require a more involved update process, regularly a migration.

The release of a new major version is not necessarily the end of life (EOL) of the previous major version. Instead, it can be decided on a case-by-case basis how long the previous major version will continue to be supported with bug fixes and especially security fixes.

Git branching strategy (branches)

Closely related to the release cycle is our Git branching strategy. All new development (as opposed to bug fixes) is done in the master branch. Before a new (minor or major) version is released, a corresponding version branch is branched by the release manager (e.g., 1.8 for CMSimple_XH 1.8.x, or 2 for CMSimple_XH 2.x.y). Bug fixes are always applied to the lowest branch still supported and immediately merged upwards from the committer to the master, even if this would result in an empty merge because the bug would not affect a higher branch.