You are here: start » core_development

Developement of the Core

Decision making

CMSimple_XH is a community driven Open Source Software which is not backed by any company or club. As such, there is no chairman, nor anybody who is particularly in a position to decide in which direction the software evolves, i.e. which features will be added, changed or removed. Instead at least for all controversial changes we have established a simple voting convention, similar to PHP's RFCs and Python's PEPs, but somewhat less formally. Perhaps after some discussion in the Forum or elsewhere everybody is free to file an issue in our Github repository proposing some change to the software. At the release manager's 1) discretion from time to time usually several of these proposals are put to vote (by adding a voting label) which is also announced in the Open Development Forum, and voting is open for 18 days. Voting simply happens by adding respective reactions (usually thumbs up or thumbs down) to the proposal, but of course, also (preferably short) comments can be added if necessary. After the vote has ended, the release manager tallies the votes (whereby votes of unknown users may be ignored), and removes the voting label replacing it with to be implemented or closing the ticket, respectively.

At least for less controversial changes also pull requests can be filed in our Github repository, and if nobody objects these can be merged after a while (at least one week) by anybody with commit permissions. Trivial bug fixes can be committed right away. However, in both cases there should also be a respective issue so we have a comprehensive and meaninful changelog. Proper refactorings (i.e. such which do not alter the behavior), typo fixes etc., can be committed without filing a respective issue, as these are usually irrelevant for users.

Release cycle

As of CMSimple_XH 1.7.0 the project obeys semantic versioning. There is no strictly defined timeline, but as a rule of thumb revisions (which only deploy backward compatible bug fixes) are released several times a year (in urgent cases a revision might be released only a few days after the former version), minor versions (which may introduce new features and improvements which do not break BC) are released a few times a year after having had at least one release candidate), and major versions (which may introduce back-incompabilities) are released a few years after the former major version. Major versions usually will have an extensive beta and RC phase.

Updates to new revisions and new minor releases are supposed to be as simple as uploading a patch distribution which usually does not overwrite configuration, language or stylesheets. Major versions, on the other hand, may require a more elaborate update process, often a migration.

The release of a new major version is not necessarily the end-of-life of the former major release. Instead it may be decided on a case by case basis how long the former major version will still be supported with bug and particularly security fixes.

Git branching strategy

Closely related to the release cycle is our Git branching strategy. All new development (opposed to bug fixes) happens in the master branch. Around the GA release of a new (minor or major) version a respective version branch is branched (for instance, 1.8 for CMSimple_XH 1.8.x, or 2 for CMSimple_XH 2.x.y) by the release manager. Bug fixes will always be applied to the lowest still supported branch, and immediately be merged upwards until master by the committer, even if that would result in an empty merge because the bug wouldn't affect a higher branch.

1)
a role which is not clearly defined, yet
 
You are here: start » core_development
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
Valid XHTML 1.0 Valid CSS Driven by DokuWiki