doc: define and reference the current release #174
Conversation
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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...)
|
@Fishrock123 @sam-github any objections to this as it stands? |
|
Not sure if this change is still relevant. The current readme language seems very close. Will close this but can reopen if necessary |
This is in reference to https://github.com/nodejs/node/pull/10343/files where I had included a section on the current release on the basis it hadn't been clearly defined anywhere. These small modifications to the README.md should be enough to render my separate section on backporting to current unnecessary in that PR.