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: add LTS info to COLLABORATOR_GUIDE.md #3442

Closed
wants to merge 1 commit into from
Closed

doc: add LTS info to COLLABORATOR_GUIDE.md #3442

wants to merge 1 commit into from

Conversation

MylesBorins
Copy link
Contributor

There is currently no information in the Collaborators
guide regarding LTS. This commit adds some basic copy
explaining what LTS is, what is considered for LTS,
and a simple way collaborators can help.

Consider this commit for LTS.

Closes #3412

@MylesBorins
Copy link
Contributor Author

/cc @jasnell @rvagg

@mscdex mscdex added the doc Issues and PRs related to the documentations. label Oct 19, 2015
#### How can I help?
When you send your pull request consider including information about
whether your change is breaking. If you think your patch can be backported
simply add to the commit message ```Consider this commit for LTS```.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't the lts-watch tags for exactly this purpose?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was imagining that if new commits came in and that information was provided it could streamline the process and allow people to add the LTS review tag without having to dive into the code too much

@silverwind
Copy link
Contributor

How about some words on who's doing the backporting?

@MylesBorins
Copy link
Contributor Author

@silverwind are you imagining that this would discuss the LTS working group?

@silverwind
Copy link
Contributor

@thealphanerd see #3360 (comment)

@MylesBorins
Copy link
Contributor Author

tweaked the copy a bit and added information about the release team.

@silverwind please let me know if this is inline with what you were imagining

#### What is LTS?

Long Term Support (often referred to as LTS) is the process of
backporting non breaking changes to older versions of Node.js. LTS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: non-breaking (hyphenate)

@Trott
Copy link
Member

Trott commented Oct 20, 2015

Long Term Support (often referred to as LTS) is the process of backporting non breaking changes to older versions of Node.js.

I don't think that's a good summary of LTS. Instead, it's a description of something that needs to happen as a result of LTS. If you don't want to explain what LTS is in full (and I think the way you subsequently link to a separate document for that is wise), you can make this sentence correct by changing it to:

Non-breaking changes will be backported to Long Term Support (LTS) releases.

If the LTS Plan doc is correct, then "non-breaking changes" will actually need to be changed to "bugfixes". LTS Plan says no new features. (Maybe that's been changed and the plan is to incorporate semver-minor changes?)


#### Who is doing the backporting?

Currently all backporting is being done by the release team.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(@nodejs/release) / link to https://github.com/orgs/nodejs/teams/release

@MylesBorins
Copy link
Contributor Author

@Trott I was considering "non breaking changes" to refer to the variety of supported fixes... but I can see how it can be seen as including features... tweaking copy now

@MylesBorins
Copy link
Contributor Author

Copy has been updated. I accounted for all the nits. I then simplified the copy in "What is LTS" and added a section "How does LTS work?" that directly takes the copy from the LTS plan

@MylesBorins
Copy link
Contributor Author

@Fishrock123 it just struck me that the link for @nodejs/release does not work if you are not a member of the org.

#### What is *LTS*?

Long Term Support (often referred to as LTS) guarantee application developers
a 30 month support cycle with specific versions of Node.js.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

guarantees rather than guarantee

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

boop

@MylesBorins
Copy link
Contributor Author

Ok I just pushed an update that took into account all of @Trott's above suggestions.

I decided to remove the paragraph listing what would be backported, as it is now included in the how does LTS work paragraph

@Trott
Copy link
Member

Trott commented Oct 20, 2015

👍


#### How does LTS work?

Once a release enters LTS, no new features may be added to that release. Changes are limited to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'Once a stable branch enters LTS, no new features may be added to that branch.' -- the release doesn't enter LTS, the stable branch transitions to LTS.

@MylesBorins
Copy link
Contributor Author

@jasnell updates made according to your notes

As that copy was taken from nodejs/lts I'll make a PR to update the copy there (once this is merged)


#### Who is doing the backporting?

Currently all backporting is being done by [@nodejs/release](https://github.com/nodejs/node/blob/master/README.md#release-team).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current plan is for commits to cherry pick into a staging branch first (e.g. v4.x-staging), which can be done by anyone -- in fact, the preference would be for the person landing the commit in master to also land the commit in the staging branch around the same time if the commit needs to land in the LTS. Then, when the LTS WG determines that a new LTS release is required, selected commits will be picked from the staging branch to the release branch (from from v4.x-staging to v4.x. It would be the responsibility of the person preparing the commit to pull the commits out of the v4.x-staging branch. The LTS WG works with the Release team on this process.

@MylesBorins
Copy link
Contributor Author

@jasnell I took another pass at the copy for who backports and added a section for how releases are made. Let me know what you think

@jasnell
Copy link
Member

jasnell commented Oct 21, 2015

LGTM

@jasnell
Copy link
Member

jasnell commented Oct 22, 2015

@nodejs/lts ... quick review before this lands?

There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.
@MylesBorins
Copy link
Contributor Author

@nodejs/lts bueler?

@srl295
Copy link
Member

srl295 commented Oct 28, 2015 via email

jasnell pushed a commit that referenced this pull request Oct 28, 2015
There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.

Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Steven R. Loomis <srloomis@us.ibm.com>
PR-URL: #3442
@jasnell
Copy link
Member

jasnell commented Oct 28, 2015

Landed in d394e9e

@jasnell jasnell closed this Oct 28, 2015
rvagg pushed a commit to rvagg/io.js that referenced this pull request Oct 29, 2015
There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.

Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Steven R. Loomis <srloomis@us.ibm.com>
PR-URL: nodejs#3442
MylesBorins pushed a commit that referenced this pull request Nov 17, 2015
There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.

Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Steven R. Loomis <srloomis@us.ibm.com>
PR-URL: #3442
@MylesBorins
Copy link
Contributor Author

landed in v4.x-staging in 9ce1f75

MylesBorins pushed a commit that referenced this pull request Dec 4, 2015
There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.

Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Steven R. Loomis <srloomis@us.ibm.com>
PR-URL: #3442
@jasnell jasnell mentioned this pull request Dec 17, 2015
MylesBorins pushed a commit that referenced this pull request Dec 17, 2015
There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.

Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Steven R. Loomis <srloomis@us.ibm.com>
PR-URL: #3442
MylesBorins pushed a commit that referenced this pull request Dec 23, 2015
There is currently no information in the Collaborators guide regarding
LTS. This commit adds some basic copy explaining what LTS is, what is
considered for LTS, and a simple way collaborators can help.

Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Steven R. Loomis <srloomis@us.ibm.com>
PR-URL: #3442
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants