Difference between revisions of "How to release LDC"

From D Wiki
Jump to: navigation, search
(Add LDC to d.godbolt.org)
 
(One intermediate revision by the same user not shown)
Line 24: 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 41: 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