You are here: start » core_development

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

core_development [2018/10/26 15:33] (current)
Line 1: Line 1:
 +====== 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 [[https://​wiki.php.net/​rfc|PHP'​s RFCs]] and [[https://​www.python.org/​dev/​peps/​|Python'​s PEPs]], but somewhat less formally. Perhaps after some discussion in the [[https://​cmsimpleforum.org|Forum]] or elsewhere everybody is free to file an issue in [[https://​github.com/​cmsimple-xh/​cmsimple-xh|our Github repository]] proposing some change to the software. At the **release manager**'​s ((a role which is not clearly defined, yet)) 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 [[https://​cmsimpleforum.com/​viewforum.php?​f=29|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 [[https://​github.com/​cmsimple-xh/​cmsimple-xh|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 **[[http://​semver.org/​|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.
 
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