Difference between revisions of "How to release LDC"

From D Wiki
Jump to: navigation, search
(Add LDC to d.godbolt.org)
 
(4 intermediate revisions by 2 users not shown)
Line 4: Line 4:
  
 
* Establish consensus among the developers about the plan to release a new version. This will at least involve some discussion on the project mailing list.
 
* Establish consensus among the developers about the plan to release a new version. This will at least involve some discussion on the project mailing list.
* Make sure that Git mater is in a reasonably stable state, i.e. that at least all the CI tests at [https://travis-ci.org/ldc-developers/ldc Travis] and [http://ci.lycus.org ci.lycus.org] pass.
+
* Make sure that Git mater is in a reasonably stable state, i.e. that at least all the CI tests at [https://travis-ci.org/ldc-developers/ldc Travis] , AppVeyor, and CircleCI pass (there will be more buildbots in the future!).
 
* Create a new Git branch called <tt>release-x.y.z</tt>, and announce this on the project mailing list. Git master is now open for development again.
 
* Create a new Git branch called <tt>release-x.y.z</tt>, and announce this on the project mailing list. Git master is now open for development again.
 
* Make sure that LDC passes the extended set of release qualification tests (see below); if any failures are discovered, work on resolving them.
 
* Make sure that LDC passes the extended set of release qualification tests (see below); if any failures are discovered, work on resolving them.
 
* Release a first beta version:
 
* Release a first beta version:
**Create Git tags in the ldc (<tt>vX.Y.Z-beta1</tt>), druntime and Phobos (<tt>ldc-vX.Y.Z-beta1</tt>) repositories. Do this before compiling the binary packages so the version name is picked up by CMake.
+
**Create annotated Git tags in the ldc (<tt>git tag -a vX.Y.Z-beta1</tt>), druntime and Phobos (<tt>git tag -a ldc-vX.Y.Z-beta1</tt>) repositories. Do this before compiling the binary packages so the version name is picked up by CMake.
 
**Compile binary packages as described below.
 
**Compile binary packages as described below.
 
**Build a full source package including all the submodules, e.g. using git-archive-all.
 
**Build a full source package including all the submodules, e.g. using git-archive-all.
Line 15: Line 15:
 
*Update the package links on the wiki.
 
*Update the package links on the wiki.
 
*Submit a pull request for the links at http://dlang.org/download.html.
 
*Submit a pull request for the links at http://dlang.org/download.html.
*[https://github.com/ldc-developers/ldc-developers.github.io/edit/master/LATEST Edit] the https://ldc-developers.github.io/LATEST file for use by Travis CI.
+
*[https://github.com/ldc-developers/ldc-developers.github.io/edit/master/LATEST Edit] the https://ldc-developers.github.io/LATEST file for use by Dlang's installer script (e.g. used by Travis CI).
 +
** [https://github.com/ldc-developers/ldc-developers.github.io/edit/master/LATEST_BETA Edit] the https://ldc-developers.github.io/LATEST_BETA file for beta releases or update to the latest release whichever is newer.
 +
** [https://github.com/ldc-developers/ldc-developers.github.io/edit/master/LATEST_LTS Edit] the https://ldc-developers.github.io/LATEST_LTS file for LTS release.
 
*Announce the release on:
 
*Announce the release on:
 
**digitalmars.d.announce
 
**digitalmars.d.announce
Line 22: Line 24:
 
**IRC (#d/#ldc on freenode, update channel titles)
 
**IRC (#d/#ldc on freenode, update channel titles)
 
**Twitter (#dlang)
 
**Twitter (#dlang)
 +
* Bump the version number in the master branch.
  
 
== Release qualification tests ==
 
== Release qualification tests ==
Line 39: Line 42:
  
 
After the packages are done, be sure to smoke-test them by compiling a Hello World program in a clean environment.
 
After the packages are done, be sure to smoke-test them by compiling a Hello World program in a clean environment.
 +
 +
== Adding the release to d.godbolt.org ==
 +
 +
* add the new compiler to gcc-explorer-image, by patching https://github.com/mattgodbolt/gcc-explorer-image/blob/master/update_compilers/install_compilers.sh. Look for "ldc".
 +
* add the compiler to the list in d.amazon.properties: https://github.com/mattgodbolt/gcc-explorer/blob/master/etc/config/d.amazon.properties
  
 
[[Category:LDC]]
 
[[Category:LDC]]

Latest revision as of 16:09, 9 November 2016

This document is intended for maintainers/release managers of the LDC project and describes the steps necessary to release a new version of LDC to the public.

First, a quick outline of the process. For more details, see the later sections.

  • Establish consensus among the developers about the plan to release a new version. This will at least involve some discussion on the project mailing list.
  • Make sure that Git mater is in a reasonably stable state, i.e. that at least all the CI tests at Travis , AppVeyor, and CircleCI pass (there will be more buildbots in the future!).
  • Create a new Git branch called release-x.y.z, and announce this on the project mailing list. Git master is now open for development again.
  • Make sure that LDC passes the extended set of release qualification tests (see below); if any failures are discovered, work on resolving them.
  • Release a first beta version:
    • Create annotated Git tags in the ldc (git tag -a vX.Y.Z-beta1), druntime and Phobos (git tag -a ldc-vX.Y.Z-beta1) repositories. Do this before compiling the binary packages so the version name is picked up by CMake.
    • Compile binary packages as described below.
    • Build a full source package including all the submodules, e.g. using git-archive-all.
    • Announce the beta version on the project forum, IRC (freenode) and digitalmars.D.announce.
  • Repeat the last step until no more regressions compared to the last release are reported, then one last time for the final release.
  • Update the package links on the wiki.
  • Submit a pull request for the links at http://dlang.org/download.html.
  • Edit the https://ldc-developers.github.io/LATEST file for use by Dlang's installer script (e.g. used by Travis CI).
  • Announce the release on:
  • Bump the version number in the master branch.

Release qualification tests

  • Make sure the code base passes the test suite (ctest -j<n>) in the follwing configurations:
    • Linux x86
    • Linux x86_64, multilib enabled
    • OS X 10.7, multilib enabled
  • Make sure that the different combinations of the BUILD_BC_LIBS and BUILD_SHARED_LIBS at least build and install on Linux/OS X (multilib on) as to not block further progress (todo: post testing scripts to GitHub).
  • Make sure all the version numbers are up to date and LDMD has also been adapted to the new frontend version.

Building binary packages

The Linux binary packages are built on the second-to-last Ubuntu LTS release for compatibility. An easy way to do this is to just choose from the official Ubuntu Cloud Guest images and run them on an Amazon EC2 instance (m1.small should be enough).

The scripts used for building the packages are part of the ldc-scripts repository.

After the packages are done, be sure to smoke-test them by compiling a Hello World program in a clean environment.

Adding the release to d.godbolt.org