Show your support for Zikula! Sign up at Github account and watch the Core project!
- craigh responded to »Changing the order in which module CSS is loaded« 08:24 AM
- espaan responded to »Experience of upgrading site from Zikula 1.2.4 to 1.3.6« 08. Dec
- henn9438 responded to »Ajax security checks failed« 06. Dec
- espaan responded to »status of getstatusmsg« 02. Dec
- MarcPare created topic »1.3.6 Security Update« 22. Nov
- craigh responded to »Downloads module 3.1.3 has an access issue.« 20. Nov
- localrags responded to »Installing Outbrain script in Zikula 1.2.9« 17. Nov
Articles: Changes to Module Branch, Tag and Versioning
Since we started using GIT some years ago, a branch and tagging convention has grown in the PHP community and been cemented by Composer PHP dependency management. These changes to branch and tag naming are compulsory for Zikula modules and will aid future automation.
Modules must be released with versioning that represents the a.b.c Semantic Versioning (http://semver.org/). For example 2.3.0, 2.3.1 … 2.3.12 and so on. Where the c is the maintenance (bugfix) version.
If you maintain just one version series, then you should have just the master branch. e.g.
master - Your development branch
If you maintain more than one bugfix branch (e.g. 2.3 and 2.4 series) as well as a current new version, you must name them like this:
2.3 - maintenance branch of 2.3.x series 2.4 - maintenance branch of 2.4.x series master - latest development branch (could be 2.5, 2.6 or even 3.0 doesn’t matter)
When tagging releases you must tag them as the final release version so 2.3.1 would be tagged 2.3.1, 2.4.0 would be tagged 2.4.0. You can optionally prefix it with a ‘v’, e.g. v2.3.0 but that is entirely optional. Remember Semantic Versioning allows a.b.c-d so you can also tag beta/rc releases if you wish, e.g. 2.3.0-beta1
When making bug fixes you’d always commit to the lowest branch where the fix should be applied, and then merge up. For example.
git checkout 2.3 # commit a set of fixes git checkout 2.4 git merge 2.3 # merges the 2.3 branch to current checkout (2.4) git checkout master git merge 2.4 # merges the 2.3 branch to current checkout (master)
Renaming branches is as simple as follows. Let’s rename release-3 to 3.4
git checkout -b 3.4 release-3 git push origin 3.4 git branch -D release-3 git push origin :release-3