Version 6 (modified by Chris Johns, on May 3, 2015 at 5:53:47 AM) (diff)

Release stages.

Release Procedures

This page details the various stages, processes and procedures required to create a release of RTEMS.

The RTEMS Project is a volunteer effort and only maintains the current and one previous release. Users wishing to have older releases maintained should enquire about commercial support offerings. The RTEMS Project attempts to provide access to previous releases.

Release Stages

The source code in the various git repositories and in one of the following stages as a release is created:

Stage Description
MASTER-OPEN The master branch in all repositories is open and new features and potentially unstable changes can be committed. Users should expect unstable behaviour.
MASTER-SLUSHY The repositories are closed to new features. Features existing in the master branch can be completed. Users should expect unstable behaviour.
MASTER-FROZEN The repositories are closed to all changes except bug fixes.
RELEASE-BRANCH A release branch is made in each repository once all the repositories pass the required release test requirements. The master branch returns to the MASTER-OPEN stage. Only bug fixes can be added to release branches. A release branch is tagged with each release as it is created. The release branch remains open until it is archived.
RELEASE-ARCHIVED The release branch is archived. No further changes are made to the branch.

A release is made when the repository contents are configured and packaged and made available as file.

Only the current and previous release branches are and active and all other release branches are archived.

Source Checklist

The items in these lists are in no particular order and subject to discussion, additions, and deletions.

The following are things that MUST be resolved before a release is made

  • Tools stabilized on known versions, these can be different versions if required.
    • If it is not possible for a tool to be built it must be well documented in the release notes.
  • All BSPs must build without error

The following are things that WOULD BE NICE to be resolved before a release is branched

  • Warning reduction pass
    • Focus on all SPARC BSPs, select PowerPC, ARM and MIPS

Required BSPs and Conditions

These BSPs must build and have all tests without errors.

  • sparc/erc32
  • ...

Coverage reports for these BSPs

  • sparc/erc32

Release Checklist

Main release steps.



  1. Create branch for release


  1. Announcement


  1. Bump default version to the current release
  2. Generate 'next' milestone


  1. Upload file to FTP with sha256.


  1. Generate docs from branch.
    1. Texinfo
    2. Doxygen
    3. RSB
  2. Update

Tarball Generation

  1. Run bootstrap
  2. Generate ChangeLog using script found in #2208


There are no snapshots as of yet.