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.

Sign up for GitHub

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: define and reference the current release #174

Closed
wants to merge 1 commit into from
Closed

doc: define and reference the current release #174

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
9 changes: 5 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,9 +54,10 @@

# LTS Plan

New semver-major releases of Node.js are cut from `master` every six months.
New even-numbered versions (e.g. v6, v8, v10, etc) are cut in April. New
odd-numbered versions (e.g. v5, v7, v9) are cut in October.
New semver-major releases of Node.js are cut from `master` every six months
and become the "current" release. New even-numbered versions (e.g. v6, v8,
v10, etc) are cut in April. New odd-numbered versions (e.g. v5, v7, v9)
are cut in October.
Copy link
Contributor

Choose a reason for hiding this comment

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

somewhere it says how Current is maintained? That it gets an arbitrary[xx] set of patch and minor's cherry-picked form master and proposed in a github PR?

xx Shouldn't be arbitrary, but I'm not dead sure on the criteria.

Copy link
Member Author

Choose a reason for hiding this comment

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

Suspect any additional detail on the criteria that is required in this particular doc should come have input from @thealphanerd, @Fishrock123 or others. We could add a phrase about it being at the discretion from the release team taking into account the labels on the original PRs

Copy link
Contributor

@sam-github sam-github Dec 29, 2016 •
edited
Loading

Choose a reason for hiding this comment

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

@thealphanerd @Fishrock123 I keep mentioning this because one of the io.js fork drivers was semver-minors sitting on joyent/node master for years, with no way to know when they would hit a supported release (EDIT: I wrote "master" by mistake). Release cadences are universes better now, and for contributors or observers to be able to predict when commits from any particular PR (barring negative reports on it after merging to master) will hit any particular release stream would be really helpful.

Copy link
Contributor

Choose a reason for hiding this comment

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

Any info on the Current branch should be in the main repo IMO.

Anyone can propose minor or patch releases on it, although that is not clear. If no-one else does, one of the releasers will. We aim for every week to every other week, although sometimes releases slip to 3.

Anything that can land and isn't breaking (or depending on a breaking change), we land it on Current. (Occasionally we decide to do a patch anyways rather than a minor if there are few minors, releaser's discretion.)

and for contributors or observers to be able to predict when commits from any particular PR (barring negative reports on it after merging to master) will hit any particular release stream would be really helpful.

If you want something expedited, just propose a release... or even do some of the pre-release work. :P

Copy link
Member

Choose a reason for hiding this comment

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

Any info on the Current branch should be in the main repo IMO.

You mean because the LTS repo should only contain info about the LTS branches? It seems weird to split up the current and LTS stuff, not least because current is sort-of defined as halfway between master and lts. Would you document what the current branch is without documenting the LTS branches?

At the moment the only documentation that current branches are a thing is in this README (as far ask I know).

Copy link
Member Author

Choose a reason for hiding this comment

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

I think a small amount understand of information in here is valid in order to make it easy for people to understand what the term "current" means as opposed to LTS, and my current PR reflects that as there isn't much written about it anywhere at the moment. There is the question of where you put any more information that is currently in this PR regarding the processes surrounding how things are selected and put into current

From a contributor perspective (and this PR came about as a result of an update I was making to CONTRIBUTOR.md) the process for getting things into current and LTS is broadly the same, but the selection process isn't.

@Fishrock123 Which documentation file in the main repository were you thinking of for that additional information? I don't want to make the contributor process any more complex than it needs to be by directing new contributors to too many different places (which may suggest that having it in CONTRIBUTING.md could be the main repo is the right place - I think it should be there or here for simplicity...)


When a new *odd-numbered* major release is cut, the previous *even-numbered*
major version transitions to the Long Term Support plan.
Expand Down Expand Up @@ -116,6 +117,6 @@ only landed in the `v4.x` branch when a new `v4.x` release is being prepared.**
## Node abstraction layer

It should be stated that the abstraction layer (currently `NAN`) should
support all *current* LTS releases. Given that Active LTS will overlap
support all current and LTS releases. Given that Active LTS will overlap
for a period of 6 months, this means that the abstraction layer will, at
any given point in time, fully support a maximum of 2 LTS releases.