Changes between Version 7 and Version 8 of Developer/Release


Ignore:
Timestamp:
05/03/15 09:02:52 (9 years ago)
Author:
Chris Johns
Comment:

Edits.

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Release

    v7 v8  
    1 = Release Procedures =
     1= Release Procedures
    22
    33[[TOC(Developer/Release, depth=4)]]
     
    55This 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.
    66
    7 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.
     7The 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.
    88
    9 = Release Stages =
     9== Release Stages
    1010
    11 The source code in the various git repositories and in one of the following stages as a release is created:
     11The source code in the various git repositories will be in one of the following stages:
    1212
    1313||= '''Stage''' =||= '''Description''' =||
    14 ||= `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. ||
    15 ||= `MASTER-SLUSHY` =|| The repositories are closed to new features. Features existing in the master branch can be completed. Users should expect unstable behaviour. ||
    16 ||= `MASTER-FROZEN` =|| The repositories are closed to all changes except bug fixes. ||
    17 ||= `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. ||
    18 ||= `RELEASE-ARCHIVED` =|| The release branch is archived. No further changes are made to the branch. ||
     14||= `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. ||
     15||= `MASTER_SLUSHY` =|| The repositories are closed to new features. Features existing in the master branch can be completed. Users should expect unstable behaviour. ||
     16||= `MASTER_FROZEN` =|| The repositories are closed to all changes except bug fixes. ||
     17||= `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. ||
     18||= `RELEASE_ARCHIVED` =|| The release branch is archived. No further changes are made to the branch. ||
    1919
    20  * The master branch stage changes 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.
    21  * Features for a master branch should be listed as an open project or part of ticket.
    22  * A release is the creation of any generated files and packaging of the source in a repository making the package available as a file.
     20 * 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.
     21 * Features for a master branch should be listed as an enhancement ticket.
     22 * 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.
    2323 * Only the current and previous release branches are active and all other release branches are archived.
    2424 * A release branch is a ''git branch'' pushed to the repositories.
    2525 * A release is a ''git tag'' on a release branch with the tags pushed to the repositories.
     26 * An archived release branch cannot be changed.
    2627
    27 = RTEMS Release Repositories =
     28== RTEMS Release Repositories
    2829
    2930The following repositories are part of an '''RTEMS''' release:
     
    3536 * The release branches and tags must be consistent across these repositories.
    3637
    37 = RTEMS Release Numbering and Naming =
     38== RTEMS Release Numbering and Naming
    3839
    3940The 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`.
     
    4546 Release:: The ''release'' version number change for release branch release created on a release branch after the branch has been created.
    4647
    47 == RTEMS Branch Labels ==
     48=== RTEMS Branch Labels
    4849
    4950The '''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`.
     
    5152A development release is any code taken from the master branch of a repository.
    5253
    53 == RTEMS Release 4 Series Numbering ==
     54=== RTEMS Release 4 Series Numbering
    5455
    5556Release 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.
     
    5758The 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.
    5859
    59 == RTEMS Release 5 Series And Higher Numbering ==
     60=== RTEMS Release 5 Series And Higher Numbering
    6061
    6162Release 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.