How to release LDC

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).
  • Edit the https://ldc-developers.github.io/LATEST_BETA file for beta releases or update to the latest release whichever is newer.
  • Edit the https://ldc-developers.github.io/LATEST_LTS file for LTS release.
• Announce the release on:
  • digitalmars.d.announce
  • digitalmars.d.ldc
  • Google+ (https://plus.google.com/communities/100033468228217743303)
  • IRC (#d/#ldc on freenode, update channel titles)
  • Twitter (#dlang)
• 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.