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

tools: add 12.x to alternative docs versions #27658

Closed
wants to merge 2 commits into from

Conversation

richardlau
Copy link
Member

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. tools Issues and PRs related to the tools directory. labels May 12, 2019
@nodejs-github-bot
Copy link
Collaborator

@mscdex
Copy link
Contributor

mscdex commented May 12, 2019

Perhaps this kind of thing could be added to the list of tasks when cutting a new major version (if such a thing exists) to avoid missing this in the future?

@richardlau
Copy link
Member Author

richardlau commented May 12, 2019

Perhaps this kind of thing could be added to the list of tasks when cutting a new major version (if such a thing exists) to avoid missing this in the future?

Should be added to #25497. I'll add a comment there. (edit: #25497 (comment).)

@BridgeAR
Copy link
Member

I would actually like to automate this instead of making it part of our release process. We are definitely able to already detect the possible versions by parsing the changelog folder and their filenames. This won't provide us with any information about the current LTS status though. We could just expect every even release to be LTS for releases from v6 on or shall we only mark active LTS releases as such? In that case we could also parse https://github.com/nodejs/Release/blob/master/schedule.json (but relying on another repository does not seem ideal).

I might also have missed more ways to automate this but I really think we should minimize manual work as much as possible.

@richardlau
Copy link
Member Author

I would actually like to automate this instead of making it part of our release process. We are definitely able to already detect the possible versions by parsing the changelog folder and their filenames. This won't provide us with any information about the current LTS status though. We could just expect every even release to be LTS for releases from v6 on or shall we only mark active LTS releases as such? In that case we could also parse https://github.com/nodejs/Release/blob/master/schedule.json (but relying on another repository does not seem ideal).

I might also have missed more ways to automate this but I really think we should minimize manual work as much as possible.

That's not a bad idea -- I can take a look at that.

@richardlau
Copy link
Member Author

I would actually like to automate this instead of making it part of our release process. We are definitely able to already detect the possible versions by parsing the changelog folder and their filenames. This won't provide us with any information about the current LTS status though. We could just expect every even release to be LTS for releases from v6 on or shall we only mark active LTS releases as such? In that case we could also parse https://github.com/nodejs/Release/blob/master/schedule.json (but relying on another repository does not seem ideal).
I might also have missed more ways to automate this but I really think we should minimize manual work as much as possible.

That's not a bad idea -- I can take a look at that.

Let's close this one in favour of #27661.

@richardlau richardlau closed this May 12, 2019
@richardlau
Copy link
Member Author

Reopening as a quick fix because #27661 in its current form won't work as expected outside of master.

@richardlau richardlau reopened this May 12, 2019
@nodejs-github-bot
Copy link
Collaborator

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 13, 2019
@ChALkeR
Copy link
Member

ChALkeR commented May 14, 2019

As a side note: why is 6.x labelled as LTS and 4.x is not?
Both are EOL, so those should either both have the LTS label or not (or even have an EOL label).

Refs: #20904 nodejs/Release#440

@richardlau
Copy link
Member Author

As a question: why is 6.x labelled as LTS and 4.x is not?
Both are EOL, so those should either both have the LTS label or not (or even have an EOL label).

Refs: #20904 nodejs/Release#440

@ChALkeR Good point. I've pushed another commit that marks 6.x as End-of-Life and removed the column for it from the changelog similarly to what we did for 4.x in #21612.

@nodejs-github-bot
Copy link
Collaborator

@richardlau richardlau mentioned this pull request May 14, 2019
@Trott
Copy link
Member

Trott commented May 14, 2019

Landed in 38e11cc...4a18b87

@Trott Trott closed this May 14, 2019
Trott pushed a commit to Trott/io.js that referenced this pull request May 14, 2019
PR-URL: nodejs#27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
Trott pushed a commit to Trott/io.js that referenced this pull request May 14, 2019
PR-URL: nodejs#27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
targos pushed a commit that referenced this pull request May 15, 2019
PR-URL: #27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
targos pushed a commit that referenced this pull request May 15, 2019
PR-URL: #27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 16, 2019
PR-URL: #27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 16, 2019
PR-URL: #27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 16, 2019
PR-URL: #27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
MylesBorins pushed a commit that referenced this pull request May 16, 2019
PR-URL: #27658
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Сковорода Никита Андреевич <[email protected]>
@BridgeAR BridgeAR mentioned this pull request May 21, 2019
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. doc Issues and PRs related to the documentations. tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants