New guidelines for maintenance branches
lkarsten at varnish-software.com
Thu Oct 29 16:19:17 CET 2015
I'm easing up the policy on how and who can commit to the
maintenance branches of Varnish Cache. Typically 4.0 and 4.1.
The policy is defined by this wiki node:
Contents copied from the wiki for your review:
* The maintenance branches shall represent stable and consistent solutions
for users. Users requiring the latest functionality have other options.
* The branches should always be possible to build.
* Pushed commits shall stand on their own. Documentation, test cases and any build
system changes shall accompany the functional change.
* Functionality shall not be removed in minor releases.
* Functionality shall always be commited in master before any porting
to maintenance branches.
* Changes requiring sign-off on email from the release manager:
- New features or additions ported in from master.
- Changes to global header files (cache.h in particular).
- Anything involving VRT ABI version.
- Output changes where it is reasonable to think users may parse it programmatically.
* Commits on the following can be commited by everyone freely:
- Documentation changes.
- Test case stabilization.
Commit rights will be given to active project members that request it. The
release manager decides exceptions, and may update this procedure as required.
If you are unsure, ask.
(Release manager hat on.)
More information about the varnish-dev