Difference between revisions of "DIP75"
DavidSoria (talk | contribs) (Created page with "{| class="wikitable" !Title: !'''Release Process''' |- |DIP: |75 |- |Version: |1 |- |Status: |Draft |- |Created: |2015-03-06 |- |Last Modified: |{{REVISIONYEAR}}-{{REVISIONMON...") |
(remind people to use stable branch for fixes) |
||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 10: | Line 10: | ||
|- | |- | ||
|Status: | |Status: | ||
| − | | | + | |Approved experimentally for 2.068 |
|- | |- | ||
|Created: | |Created: | ||
| Line 35: | Line 35: | ||
* synchronization with releases processes of major distributions | * synchronization with releases processes of major distributions | ||
| − | In addition the DIP proposes the idea of | + | In addition the DIP proposes the idea of '''Release Managers''', who are responsible for a timely release. |
| − | |||
| − | == | + | == Release Process == |
We propose to introduce '''bugfix versions''' and '''feature versions'''. | We propose to introduce '''bugfix versions''' and '''feature versions'''. | ||
A '''feature version''' may contain new features, language changes, | A '''feature version''' may contain new features, language changes, | ||
| Line 49: | Line 48: | ||
to release additional bugfix versions when needed. | to release additional bugfix versions when needed. | ||
| − | == Schedule == | + | === Schedule === |
| − | A bugfix version is released every month. A feature version is released | + | A bugfix version is released ''every month''. A feature version is released |
| − | every 2 months. Two weeks before a feature release ''stable'' is branched | + | every 2 months. Releases should happen on the first Saturday of the month. |
| + | Two weeks before a feature release ''stable'' is branched | ||
off ''master''. No new features are integrated into ''stable''. | off ''master''. No new features are integrated into ''stable''. | ||
| Line 71: | Line 71: | ||
=== Branching strategy === | === Branching strategy === | ||
| + | |||
| + | '''TL;DR''' Safe fixes should '''always''' go into stable, all the time. | ||
| + | |||
| + | ---- | ||
| + | |||
There are two branches: master and stable. Two weeks before a feature | There are two branches: master and stable. Two weeks before a feature | ||
release the master branch becomes stable. All subsequent ''bugfix'' | release the master branch becomes stable. All subsequent ''bugfix'' | ||
versions are tagged off the stable branch. New features go to master, | versions are tagged off the stable branch. New features go to master, | ||
which will become the next major version. Stable is regularly merged back | which will become the next major version. Stable is regularly merged back | ||
| − | into | + | into master to ensure that bugfixes make it into master. |
Branching Figure: | Branching Figure: | ||
| Line 83: | Line 88: | ||
\ \ | \ \ | ||
TAG 2.069 TAG 2.069.1 | TAG 2.069 TAG 2.069.1 | ||
| + | |||
| + | When compared to cherry-picking fixes from master, this allows us to properly track which releases contain a particular fix. It also causes less merge conflicts b/c no duplicated commits must be merged and reduces the work to identify commits on master that need to be cherry-picked. | ||
| + | The downside is that github doesn't allow to change the target branch of a PR. So if a PR inadvertently targets master, it will have to be rebased onto stable and a new PR must be opened. | ||
| + | |||
=== Security Management === | === Security Management === | ||
| − | Release managers should keep track of security | + | Release managers should keep track of security related bugs. They |
are responsible for following a ''responsible disclosure policy'' for | are responsible for following a ''responsible disclosure policy'' for | ||
| − | D. This means, set an | + | D. This means, set an expected fix date and communicate the date with |
the original vulnerability reporter. Contact packages to get ready | the original vulnerability reporter. Contact packages to get ready | ||
to publish packages at the given date and obtain an CVE if necessary. | to publish packages at the given date and obtain an CVE if necessary. | ||
| Line 98: | Line 107: | ||
There are always two or more release managers. This allows the | There are always two or more release managers. This allows the | ||
releases being independent from a single point of failure (vacation, | releases being independent from a single point of failure (vacation, | ||
| − | personal | + | personal matters, etc), and allows a smooth ramp-up for release |
managers. Release managers are responsible for releasing the | managers. Release managers are responsible for releasing the | ||
''release package'' on time. They ensure that bugfix releases do not | ''release package'' on time. They ensure that bugfix releases do not | ||
| − | contain any backwards | + | contain any backwards compatibilities and maintain the changelog. |
Release managers are free to remove features or fixes when necessary. | Release managers are free to remove features or fixes when necessary. | ||
Release managers are able to merge features and bugfixes on github. | Release managers are able to merge features and bugfixes on github. | ||
They are to provide a GPG signed tarball and a feature. Release | They are to provide a GPG signed tarball and a feature. Release | ||
managers are appointed by Walter and Andrei. | managers are appointed by Walter and Andrei. | ||
| − | |||
== Copyright == | == Copyright == | ||
Latest revision as of 17:58, 25 July 2016
| Title: | Release Process |
|---|---|
| DIP: | 75 |
| Version: | 1 |
| Status: | Approved experimentally for 2.068 |
| Created: | 2015-03-06 |
| Last Modified: | 2016-07-25 |
| Author: | David Soria Parra and Martin Nowak |
Contents
Abstract
The current release process of DMD, Druntime and Phobos (from now on referred to as "release package"), is done on a "done when it's done" basis. This DIP proposes a time-based release schedule. This allows:
- reduced times to get bugfixes out
- a clear way of managing backwards compatibility
- a more predictable release schedule for packagers
- cleaner responsibilities
- assurance to developers regarding timeliness of release of their contributions
- synchronization with releases processes of major distributions
In addition the DIP proposes the idea of Release Managers, who are responsible for a timely release.
Release Process
We propose to introduce bugfix versions and feature versions. A feature version may contain new features, language changes, and deprecations. For every release version the minor part of the version is incremented: 2.066, 2.067, ... A bugfix version is based on a feature version and contains only bugfixes and neither new features, nor deprecations of other features or library changes. Bugfix versions are for example: 2.066.1, 2.066.2, etc. There is only one supported version at a time, but release managers are free to release additional bugfix versions when needed.
Schedule
A bugfix version is released every month. A feature version is released every 2 months. Releases should happen on the first Saturday of the month. Two weeks before a feature release stable is branched off master. No new features are integrated into stable.
Example schedule:
- Dec 14th: Branch cut (master becomes stable)
- Jan 1st: 2.069
- Feb 1st: 2.069.1
- Feb 14th: Branch cut (master becomes stable)
- Mar 1st: 2.070
- Apr 1st: 2.070.1
Support and Packages
Only the most recent version is supported. Distributions are free to backport what is needed. In addition Release Managers can decided to release additional fix versions if needed. The release manager offer the source code of the release as a tarball (*.tar.gz, *.tar.xz) as well as a Windows version. All other formats are left to packagers and should be preferable automized.
Branching strategy
TL;DR Safe fixes should always go into stable, all the time.
There are two branches: master and stable. Two weeks before a feature release the master branch becomes stable. All subsequent bugfix versions are tagged off the stable branch. New features go to master, which will become the next major version. Stable is regularly merged back into master to ensure that bugfixes make it into master.
Branching Figure:
----- master --o--------o------------------------
\ / / \
stable --------------------------------- stable
\ \
TAG 2.069 TAG 2.069.1
When compared to cherry-picking fixes from master, this allows us to properly track which releases contain a particular fix. It also causes less merge conflicts b/c no duplicated commits must be merged and reduces the work to identify commits on master that need to be cherry-picked. The downside is that github doesn't allow to change the target branch of a PR. So if a PR inadvertently targets master, it will have to be rebased onto stable and a new PR must be opened.
Security Management
Release managers should keep track of security related bugs. They are responsible for following a responsible disclosure policy for D. This means, set an expected fix date and communicate the date with the original vulnerability reporter. Contact packages to get ready to publish packages at the given date and obtain an CVE if necessary. Upon release date they notify the packagers and write an announcement explaining the vulnerability and include the reporter if desired. That way we ensure a smooth handling of security problems in line with standard community processes.
Release manager
There are always two or more release managers. This allows the releases being independent from a single point of failure (vacation, personal matters, etc), and allows a smooth ramp-up for release managers. Release managers are responsible for releasing the release package on time. They ensure that bugfix releases do not contain any backwards compatibilities and maintain the changelog. Release managers are free to remove features or fixes when necessary. Release managers are able to merge features and bugfixes on github. They are to provide a GPG signed tarball and a feature. Release managers are appointed by Walter and Andrei.
Copyright
This document has been placed in the Public Domain.
