Release Process

This document specifies practical implementation of release processes at Frappe for following projects:

1. Frappe Framework
2. ERPNext
3. Any other related repository that wants to follow similar practice.

Aim of the process

• Customers should get improvements as soon as possible
• There should be little to no manual intervention for releases.
• Regressions should be minimal (low "mean time between failures")
• Regressions should be quickly addressed (low "mean time for resolution")
• Minor releases should become a "boring event" i.e. No surprises.

Revising this process

• Current process is effectively a single button press of "merge". Any future changes to this process should not increase "friction".
• E.g. If "escaped bugs" are a problem then it should be addressed by adding automated tests and not by adding another manual step/checklist in release.

Branching convention

• Bleeding edge branch: Each project should have develop branch that represents most bleeding edge version and will eventually becoming
• Stable branch: Each stable supported version should have single branch in format of version-{NUMBER} e.g. version-13
• Hotfix branch: Each stable supported version should have a single branch in format of version-{NUMBER}-hotfix as staging branch to stage changes for next release.
• A "stable release" is merging of hotfix to relevant stable branch.
• Bleeding edge, stable and hotfix branch should always be protected branches
• Beta/Pre-release branch: Any released beta version should have a single branch in format of version-{NUMBER}-beta

Release "manager"

• Each project should have single person of contact for releases to avoid volunteer dilemma.
• Frappe and ERPNext currenty have Deepesh Garg as Release manager.
• Anyone with merge rights to protected branch can create releases in event of critical fixes OR temporary unavailabilty of release manager.

Release Process

The release manager follows following procedure.

1. A github workflow creates a PR for merging hotfix into staging branches on every Tuesday.
2. This pull request runs on the automated tests, lint rules on changes. Once tests pass, the pull request is merged to pre-release and then stable branch.
3. Upon merging any change to stable branch, rest of the process is automated.

• As soon as changes are merged to stable branch semantic release workflow starts.
• Change notes are generated from merged PR/commit titles.
• Version is updated automatically based on semantic versioning[1] and conventional commit[2].
• GitHub release is automatically published.

4. Release manager should verify that automated workflow successfully released changes.

Release schedule

• Version 13 - Every week on Tuesday ~3PM
• Version 14 - Every week on Tuesday ~3PM

Exception: critical fixes are released out of schedule in form of "patch releases"

Repositories not coverd by this document

• Bench - Bench has its own separate release process: https://github.com/frappe/bench#releases
• Ecommerce Integration - Similar automated process as Frappe/ERPNext but single stable branch is maintained called main.

References:

1. semantic versioning - https://semver.org/
2. conventional commits - https://www.conventionalcommits.org/en/v1.0.0/