Difference between revisions of "DIP75"

From D Wiki
Jump to: navigation, search
(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:
|Draft
+
|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 "Release Managers", which
+
In addition the DIP proposes the idea of '''Release Managers''', who are responsible for a timely release.
is responsible for a timely release.
 
  
== Versions ==
+
== 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 msater to ensure that bugfixes make it into master.
+
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 releated bugs. They
+
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 exepcted fix date, communicate the date with
+
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 things ,etc), and allows a smooth ramp up for release
+
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 compatibiities and maintain the changelog.
+
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

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.