Maintenance branch commit guidelines

This document describes the current git commit process with regards to maintenance branches of Varnish Cache.

As of April 2016, these are the 4.0 and 4.1 branches.

Guidelines:

• 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.