From d6a5f98b36efd58d74cb4c8487901b2bac05e657 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 20 Apr 2016 17:05:54 -0700 Subject: [PATCH] doc: change references to Stable to Current With v6 we plan to rename the Stable release line to Current. This commit updates all references to Stable in the codebase. It will have to land along side updates to other repos within the org. ref: https://github.com/nodejs/nodejs.org/issues/669 --- README.md | 22 +++++++++++----------- doc/releases.md | 4 ++-- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 7c37e704dc3655..5a55009f338432 100644 --- a/README.md +++ b/README.md @@ -21,19 +21,19 @@ If you need help using or installing Node.js, please use the The Node.js project maintains multiple types of releases: -* **Stable**: Released from active development branches of this repository, +* **Current**: Released from active development branches of this repository, versioned by [SemVer](http://semver.org/) and signed by a member of the [Release Team](#release-team). - Code for Stable releases is organized in this repository by major version + Code for Current releases is organized in this repository by major version number, For example: [v4.x](https://github.com/nodejs/node/tree/v4.x). - The major version number of Stable releases will increment every 6 months + The major version number of Current releases will increment every 6 months allowing for breaking changes to be introduced. This happens in April and - October every year. Stable release lines beginning in October each year have - a maximum support life of 8 months. Stable release lines beginning in April + October every year. Current release lines beginning in October each year have + a maximum support life of 8 months. Current release lines beginning in April each year will convert to LTS (see below) after 6 months and receive further support for 30 months. * **LTS**: Releases that receive Long-term Support, with a focus on stability - and security. Every second Stable release line (major version) will become an + and security. Every second Current release line (major version) will become an LTS line and receive 18 months of _Active LTS_ support and a further 12 months of _Maintenance_. LTS release lines are given alphabetically ordered codenames, beginning with v4 Argon. LTS releases are less frequent @@ -41,7 +41,7 @@ The Node.js project maintains multiple types of releases: only incrementing patch version numbers. There are no breaking changes or feature additions, except in some special circumstances. More information can be found in the [LTS README](https://github.com/nodejs/LTS/). -* **Nightly**: Versions of code in this repository on the current Stable +* **Nightly**: Versions of code in this repository on the current Current branch, automatically built every 24-hours where changes exist. Use with caution. @@ -50,10 +50,10 @@ The Node.js project maintains multiple types of releases: Binaries, installers, and source tarballs are available at . -**Stable** and **LTS** releases are available at +**Current** and **LTS** releases are available at , listed under their version strings. The [latest](https://nodejs.org/download/release/latest/) directory is an -alias for the latest Stable release. The latest LTS release from an LTS +alias for the latest Current release. The latest LTS release from an LTS line is available in the form: latest-_codename_. For example: @@ -68,7 +68,7 @@ documentation of the latest stable version. ### Verifying Binaries -Stable, LTS and Nightly download directories all contain a *SHASUM256.txt* +Current, LTS and Nightly download directories all contain a *SHASUM256.txt* file that lists the SHA checksums for each file available for download. @@ -88,7 +88,7 @@ $ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c - _(Where "node-vx.y.z.tar.gz" is the name of the file you have downloaded)_ -Additionally, Stable and LTS releases (not Nightlies) have GPG signed +Additionally, Current and LTS releases (not Nightlies) have GPG signed copies of SHASUM256.txt files available as SHASUM256.txt.asc. You can use `gpg` to verify that the file has not been tampered with. diff --git a/doc/releases.md b/doc/releases.md index 512deb34acf84d..b7e00683693027 100644 --- a/doc/releases.md +++ b/doc/releases.md @@ -127,7 +127,7 @@ See https://github.com/nodejs/node/labels/confirmed-bug for complete and current * Include the full list of commits since the last release here. Do not include "Working on X.Y.Z+1" commits. ``` -The release type should be either Stable, LTS, or Maintenance, depending on the type of release being produced. +The release type should be either Current, LTS, or Maintenance, depending on the type of release being produced. ### 4. Create Release Commit @@ -187,7 +187,7 @@ Jenkins collects the artifacts from the builds, allowing you to download and ins Once you have produced builds that you're happy with, create a new tag. By waiting until this stage to create tags, you can discard a proposed release if something goes wrong or additional commits are required. Once you have created a tag and pushed it to GitHub, you ***should not*** delete and re-tag. If you make a mistake after tagging then you'll have to version-bump and start again and count that tag/version as lost. -Tag summaries have a predictable format, look at a recent tag to see, `git tag -v v5.3.0`. The message should look something like `2015-12-16 Node.js v5.3.0 (Stable) Release`. +Tag summaries have a predictable format, look at a recent tag to see, `git tag -v v6.0.0`. The message should look something like `2016-04-26 Node.js v6.0.0 (Current) Release`. Create a tag using the following command: