Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: change references to Stable to Current #6318

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,27 +21,27 @@ 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
and will attempt to maintain consistent major and minor version numbers,
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.

Expand All @@ -50,10 +50,10 @@ The Node.js project maintains multiple types of releases:
Binaries, installers, and source tarballs are available at
<https://nodejs.org>.

**Stable** and **LTS** releases are available at
**Current** and **LTS** releases are available at
<https://nodejs.org/download/release/>, 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:
<https://nodejs.org/download/release/latest-argon>

Expand All @@ -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.

Expand All @@ -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.

Expand Down
4 changes: 2 additions & 2 deletions doc/releases.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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:

Expand Down