varnishcache/varnish-cache
2
0
Fork 0
mirror of https://github.com/varnishcache/varnish-cache.git synced 2025-11-01 15:07:39 +00:00
Code Issues Projects Releases Packages Wiki Activity
Page: Maintenance branch commit guidelines
Pages
Coverity scans FAQ Home Maintenance branch commit guidelines Release procedure SLT inventory VDD18Q3 VDD19Q3 VDD22Q2 VDD23Q3 VDD25Q2 VIP 17: Enable Unix domain sockets for listen and backend addresses VIP 18: RST specification for code generation VIP 19: Declare ENUM types in VCC for VMODs VIP 23: Refactor VSL to support extracting structured data from "binary" log payloads VIP 24: Hitpass turning into hitmiss after ttl VIP 25: Inconsistent responses when VFP fails during streaming VIP 26: limit private prefetch VIP 27: Move some VCL variables to the catflap facility VIP 30: bereq.body_filters VIP11: Shared Memory revamp VIP12: vmod polymorphism (for type conversions) VIP13: VMOD versioning VIP14: *.body access VIP15: Specifying source address for outgoing sockets VIP16: Retire parameters aliases VIP1: PRIV_* visibility and lifetime control VIP20: Varnish ABI and packaging VIP22: include backend connection in director lookup VIP29: VCL labels and backend.list ( r option etc.) VIP2: VCL typed functions VIP30: Plumbing: vcl_raw() and vcl_pipe() VIP31: Backend connection queue VIP32: VSL API and Unset headers VIP33: Connection Pool Statistics VIP33: Socket.* CLI commands VIP34: Conservative map usage in shared memory VIP35: Retire libvgz VIP3: VCL implemented VMODS VIP4: Restrict VMOD function call sites VIP6: What does pipe mean in Varnish5? VIP7: Least connection director VIP8: No pipe in builtin.vcl in V5 VIP9: Expand VCL object support Varnish Developer Days Varnish Improvement Proposals Varnish developer wiki
1 Maintenance branch commit guidelines
Lasse Karstensen edited this page 2016-04-12 09:18:41 +02:00
Table of Contents

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.