= Release Procedures [[TOC(Developer/Release, depth=4)]] This page details the various stages, processes and procedures required to create a release of '''RTEMS'''. '''RTEMS''' is the RTEMS Realtime kernel, tools, tests and documentation. 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. The RTEMS Project attempts to provide access to previous releases as release. == Release Stages The source code in the various git repositories will be in one of the following stages: ||= '''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. All changes must have a ticket and commits must reference the ticket. 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. || * Stages changes on the master branch are announced on the [mailto:devel@rtems.org devel@rtems.org] mailing list. The decision to change is made by agreement of the core developers. There are no changes in the repositories to reflect this. The release page in the wiki will indicate the state. * Features for a master branch should be listed as an enhancement ticket. * A release is the creation of any generated files and the packaging of the source in a repository making the package available as a file. * Only the current and previous release branches are active and all other release branches are archived. * A release branch is a ''git branch'' pushed to the repositories. * A release is a ''git tag'' on a release branch with the tags pushed to the repositories. * An archived release branch cannot be changed. == RTEMS Release Repositories The following repositories are part of an '''RTEMS''' release: 1. RTEMS ([https://git.rtems.org/rtems.git git://git.rtems.org/rtems.git]) 1. RTEMS Source Builder ([https://git.rtems.org/rtems-source-builder.git git://git.rtems.org/rtems-source-builder.git]) 1. RTEMS Tools ([https://git.rtems.org/rtems-tools.git git://git.rtems.org/rtems-tools.git]) 1. RTEMS Testing Support ([https://git.rtems.org/rtems-testing.git git://git.rtems.org/rtems-testing.git]) 1. Example applications ([https://git.rtems.org/examples-v2.git git://git.rtems.org/examples-v2.git]) 1. Networking examples ([https://git.rtems.org/network-demos.git git://git.rtems.org/network-demos.git]) * The release branches and tags must be consistent across these repositories. == RTEMS Release Numbering and Naming The RTEMS Release Number and Naming relates to all repositories and packages released. The version number has three (3) numbers and the numbers are `major.minor.release`. Major:: The ''major'' version number defines the ''release series''. A ''release series'' up to RTEMS 4 has traditionally reflected changes in the user ''Application Programming Interface'' (API) and has been slow moving. RTEMS Series 5 and higher uses the ''major'' number to better reflect major feature changes in '''RTEMS'''. '''RTEMS''' has shifted to support standards base interfaces for users and this means user API are stable and not changing. Minor:: The ''minor'' version number changes for release branch created. Release:: The ''release'' version number change for release branch release created on a release branch after the branch has been created. === RTEMS Branch Labels The '''RTEMS''' release branches are labelled with a prefix of `RTEMS_` followed by the major release number and minor release delimited with an underscore (`_`) and postfixed with `_BRANCH`. For example the release branch label for RTEMS 4.11 is `RTEMS_4_11_BRANCH`. A development release is any code taken from the master branch of a repository. === RTEMS Release 4 Series Numbering Release numbering for the Series 4 releases use the minor release dot number of ''.99'' for development releases. For example the development release numbering for RTEMS 4.11 is ''4.11.99''. This allows testing of any version number related code, processes and procedures to happen with correct minor version number. The release procedure requires the release's minor dot number to be set '0' before the release branch is created and it is used for the first branch release. Further branch releases increment the minor release number when a branch release is made. === RTEMS Release 5 Series And Higher Numbering Release numbering for Series 5 and higher releases use even minor release numbers as development release and odd minor release number for releases. For example RTEMS 5.0 is a development release, that is any code taken from the master branch, and RTEMS 5.1 is an actual '''RTEMS''' release. The minor release dot number stays at ''0'' for all development releases. The release procedure requires the release's minor number is incremented to the next odd number then the release branch is created. The release minor dot number is incremented when a new release branch release is made. ---- ---- = 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 * Select BSPs must run tests without errors see [wiki:Developer/Release#RequiredBSPs Required BSPs] 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. == General == == Git == 1. Create branch for release == Website == 1. Announcement == Trac == 1. Bump default version to the current release 1. Generate 'next' milestone == FTP == 1. Upload file to FTP with sha256. == Documentation == 1. Generate docs from branch. 1. Texinfo 1. Doxygen 1. RSB 1. Update `docs.rtems.org` == Tarball Generation == 1. Run bootstrap 1. Generate !ChangeLog using script found in #2208 ---- = Snapshot = There are no snapshots as of yet.