This section describes the organization of Git Repositories for Modules in GitHub/GitLab environments operated by HumHub.
If a public module release is planned and possible in a timely manner, changes can be comitted (PR) directly in the
master Branch. (If no active
develop branch exists.)
Before making changes in the
develop branch, make sure that it is up to date, since this branch is not always used in the regular maintenance and development of the modules.
Even though the HumHub core currently follows its own versioning scheme, modules should rely on Semantic Versioning.
Increase required minimum HumHub Version
If a feature necessarily requires a newer HumHub Core version than the one specified in the current
modules.json, at least the Minor Version Part of the module must be increased.
(Changing the patch level is not sufficient in this cases.)
If the required HumHub Core version has not yet been released, the change must be made in the
develop branch of the module.
Additionally the new minimum version of HumHub should be added in the
New Version Marketplace Releases
Steps to release a new module version:
- Add release date to
docs/CHANGELOG.mdand check version number in
- Create a Git tag for the new version e.g.
git add -a "1.1.0" -m "Release 1.1.0"
For modules that are translated via our translation service on https://translate.humhub.org:
messagefiles MUST NOT be generated automatically using the
- Modifications to the
messagefiles may only be made via the translate.humhub.org site.