WooCommerce Git flow

For core development, we use the following structure and flow.

1. Five weeks before the release we tag an alpha. We publish it for community testing, but this milestone doesn’t imply a feature freeze. Issues found in the alpha are fixed with pull requests targetting trunk as usual.

2. Three weeks before the release we create a release/x.y branch off trunk and declare feature freeze: no additional pull requests will be accepted for the x.y release. We also tag a beta from the release/x.y branch.

3. If issues are found in the beta they are fixed with pull requests targeting the release/x.y branch.

4. At the end of every week during the beta cycle (at least, optionally more often) the release branch is merged back to trunk so that any fixed applied to the beta are present in future releases too:

5. One week before the release we tag a Release Candidate. As with the beta, fixes for further issues discovered are handled with pull requests to the release branch.

6. Finally, on the release day the release branch is merged one more time to trunk.

Point releases

Point releases are those tagged x.y.z where z is not zero. These are handled similarly to the beta and release candidate of the main release:

• Pull requests are merged to the release/x.y branch (no dedicated branch is created).
• The release branch is merged back to trunk when the development for a point release is in progress, and also when the release happens.

Branch naming

Prefixes determine the type of branch, and include:

• fix/
• feature/
• add/
• update/
• release/

When creating a fix branch, use the correct prefix and the issue number. Example:

		fix/12345

	

Alternatively you can summarise the change:

		fix/shipping-tax-rate-saving