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,meta: remove wait period for npm pull requests #30329

Merged
merged 1 commit into from
Nov 10, 2019
Merged
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
4 changes: 0 additions & 4 deletions doc/guides/maintaining-npm.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,6 @@ New pull requests should be opened when a "next" version of npm has
been released. Once the "next" version has been promoted to "latest"
the PR should be updated as necessary.

One week after the "latest" release has been promoted, it can land on master
assuming no major regressions are found. There are no additional constraints
for Semver-Major releases.

Copy link
Member

Choose a reason for hiding this comment

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

@Trott - what would be an advantage of doing this? IMO a one week grace period is justified as a resiliency and quality measure.

Copy link
Member Author

@Trott Trott Nov 8, 2019

Choose a reason for hiding this comment

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

@gireeshpunathil I think it makes sense to withhold it from releases, but I'm less certain that there's much advantage to delaying it landing on master. There was relevant discussion about this in #29922. In that discussion, there seem to be a lot of people (especially if you include emoji reactions) in favor of getting rid of the delay and treating npm PRs like other PRs. But I'm totally OK if someone thinks this goes too far and blocks this change. Ultimately, I'm comfortable with changing it because we can always change the rule back.

The specific Node.js release streams the new version will be able to land into
are at the discretion of the release and LTS teams.

Expand Down