-
Notifications
You must be signed in to change notification settings - Fork 88
Development on branches
We try to adhere to a semantic versioning scheme, using version numbers in a MAJOR.MINOR.PATCH form.
-
Major releases (e.g. 3.0) may introduce breaking changes (but we strive to offer an upgrade path anyway).
-
Minor releases (e.g. 2.2) include new features (and bug fixes).
-
Patch releases (e.g. 2.1.1) just fix bugs.
All regular development is done on the master branch, or on feature branches forked form master.
The master branch will become the next feature release, i.e. a minor release (currently 2.2).
We try to keep the code on master in a working state so that a git checkout is installable and runnable, but there are no guarantees - sometimes work in progress will be merged to master.
Please do consider a feature branch if your work
- is rather large and/or not ready for release, i.e. still work in progress, or
- needs further testing or will possibly contain breaking changes.
We keep feature branches for older releases, at least for the last minor release (currently 2.1), so we can fix annoying bugs and security issues.
No original work should be done on those branches unless it's targeted to that release only and should not appear in newer (feature) releases.
Bugfixes will be backported from master as necessary by cherry-picking.
These older release branches have to be kept in a releasable state at any time so security fixes can be backported and released without delay.
Please do not (add or) backport changes that
- have not been tested and/or reviewed,
- are rather large and/or breaking or
- just add new features.
When we're working on a new major release, we may choose to use a feature branch (e.g. 3.0) for that so work on master can continue. That will be decided on a case-by-case basis.