Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Release Process

To make sure a release happen as smoothly as possible, we should strive to follow the process description below. However, this being an open source project with fairly restricted resources, certain aspects, especially related to feature freeze and documentation, tend to be ignored to make timely releases at all possible.

  • The QA Process is an important prerequisite in this process and must be followed prior to making a release.

Release schedule

The project may make 3 types of releases, major, feature and bugfix.

  • Major releases will be denoted by incrementation of the first version number, ie from 1.1 to 2.0, and will consist of bugfixes, feature additions and possibly breaking changes and deprecations.
  • Feature releases will be denoted by incremenattion of the second part of the version number, ie from 1.1.2 to 1.2.0, and will consist bugfixes and feature additions.
  • Bugfix releases will be denoted by incrementation of the third part of the version number, ie from 1.1.2 to 1.1.3, or from 2.0 to 2.0.1, and will consist of bugfixes only.

Major release

  • A person to be responsible of implementing this schedule will be selected, and given a hat with Release dude on. This person will, or until replaced, be responsible for all releases, also feature and bugfix, for all releases with the same major version number.
  • As soon as possible, as detailed a view as possible of new additions should be provided.
  • In addition to new packages, eventual (and possibly breaking) rewrites and deprecation of features will be planned.
  • When the proposed feature list is ready, a tentative date for the next release will be decided upon.
  • 4 weeks prior to release, a feature freeze will be announced.
  • English documentation should be finalized by feature freeze.
  • Eventual translations of documentation should start at feature freeze and continue towards release.
  • At release:
    • A tag will be made in SVN.
    • A branch for feature releases and bugfix releases will be made in SVN.
    • Tango will be packaged, and put up for download.
    • A release announcement will be released to all applicable receivers.

Feature release

  • As soon as possible, as detailed a view as possible of new additions should be provided. The number of new packages should be small, preferably no more than 3.
  • No breaking rewrites or deprecations will be considered.
  • When the proposed feature list is ready, a tentative date for the next release will be decided upon.
  • 2 weeks prior to release, a feature freeze will be announced.
  • English documentation should be finalized by feature freeze.
  • Eventual translations of documentation should start at feature freeze and continue towards release.
  • At release:
    • A tag will be made in SVN.
    • Tango will be packaged, and put up for download.
    • A release announcement will be released to all applicable receivers.

Bugfix release

  • No new features will be allowed in a bugfix release
  • All known bugs in the current major/feature release will be assigned to this milestone
  • When all known bugs are fixed/all tickets assigned to this milestone closed, a release will be made
  • At release:
    • A tag will be made in SVN.
    • Tango will be packaged, and put up for download.
    • A release announcement will be released to all applicable receivers.

Effect of compiler releases

Generally, this should not be a problem, except for cases where a change in the compiler/runtime interface has occurred for a given compiler release, where that leads to newer Tango code not being compilable or linkable with compiler older than the new version in question. If that happens, the following things should be done:

  • New Tango release should mark the new compiler version as a minimum requirement
  • The last revision prior to commit of the new interface should be tagged