Skip to content

ci: regenerate release svg automatically - #1119

Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom
araujogui:feat/release-workflow
Closed

ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom
araujogui:feat/release-workflow

Conversation

@araujogui

@araujoguiaraujogui commented Aug 29, 2025

Copy link
Copy Markdown
Member

Related nodejs/nodejs.org#8101

Create a workflow to automatically re-generate the release schedule SVG weekly.

@araujoguiaraujogui mentioned this pull request Aug 29, 2025
Closed
@nschonni

nschonni commented Aug 29, 2025•
edited
Loading

Copy link
Copy Markdown
Member

I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo

AugustinMauroy
AugustinMauroy reviewed Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui

araujogui commented Aug 30, 2025

Copy link
Copy Markdown
MemberAuthor

I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo

Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).

AugustinMauroy
AugustinMauroy approved these changes Aug 30, 2025
View reviewed changes

@AugustinMauroyAugustinMauroy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGMT !

ovflowd
ovflowd approved these changes Aug 31, 2025
View reviewed changes

@ovflowdovflowd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?

@targos

targos commented Sep 2, 2025•
edited
Loading

Copy link
Copy Markdown
Member

Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).

@targos

targos commented Sep 2, 2025

Copy link
Copy Markdown
Member

Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).

@araujogui

araujogui commented Sep 2, 2025

Copy link
Copy Markdown
MemberAuthor

Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).

Got it, issue fixed. I also pinned package versions

octavio12345300
octavio12345300 approved these changes Sep 3, 2025
View reviewed changes

@octavio12345300octavio12345300 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

listo

@araujogui

araujogui commented Sep 8, 2025

Copy link
Copy Markdown
MemberAuthor

CC @nodejs/releasers

@aduh95

aduh95 commented Sep 8, 2025

Copy link
Copy Markdown
Contributor

I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.
How big of a deal is it if this repo is updated manually every once in a while?

@araujogui

araujogui commented Sep 8, 2025

Copy link
Copy Markdown
MemberAuthor

I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?

I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info

@aduh95

aduh95 commented Sep 8, 2025

Copy link
Copy Markdown
Contributor

the website will start displaying misleading info

The website can (should) generate its own SVG, there's no reason to use the one in this repo

@araujogui

araujogui commented Sep 9, 2025•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

the website will start displaying misleading info

The website can (should) generate its own SVG, there's no reason to use the one in this repo

what do you think @nodejs/nodejs-website? any concerns?

@ovflowd

ovflowd commented Sep 10, 2025

Copy link
Copy Markdown
Member

the website will start displaying misleading info

The website can (should) generate its own SVG, there's no reason to use the one in this repo

what do you think @nodejs/nodejs-website? any concerns?

I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO

@ovflowd

ovflowd commented Nov 26, 2025

Copy link
Copy Markdown
Member

@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.

@aduh95

aduh95 commented Nov 27, 2025

Copy link
Copy Markdown
Contributor

My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.

@richardlau

richardlau commented Nov 27, 2025

Copy link
Copy Markdown
Member

There's little to no benefit for the Release WG to have the svg update automatically/regularly.

The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.
e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.

I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.

Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.

@ovflowd

ovflowd commented Nov 27, 2025

Copy link
Copy Markdown
Member

These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.

@ovflowd

ovflowd commented Dec 25, 2025

Copy link
Copy Markdown
Member

These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.

Bump, @araujogui

@araujoguiaraujogui mentioned this pull request Jan 9, 2026
Merged
@araujoguiaraujogui mentioned this pull request Jan 17, 2026
Open
5 tasks
@ovflowd

ovflowd commented Jan 17, 2026

Copy link
Copy Markdown
Member

@araujogui this PR can be closed btw.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

6 more reviewers
@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
ci: regenerate release svg automatically by araujogui · Pull Request #1119 · nodejs/Release · GitHub
Skip to content
ci: regenerate release svg automatically - #1119
Closed
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Closed
ci: regenerate release svg automatically#1119
araujogui wants to merge 5 commits into
nodejs:mainfrom 
araujogui:feat/release-workflow
Conversation
@araujogui
@araujoguiaraujogui
commented
Aug 29, 2025

Copy link


Copy Markdown

Member
Related nodejs/nodejs.org#8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
@araujoguiaraujogui
mentioned this pull request
Aug 29, 2025

Closed

@nschonni
nschonni
commented
Aug 29, 2025•

edited

Loading

Copy link


Copy Markdown

Member
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
AugustinMauroy
AugustinMauroy
reviewed
Aug 30, 2025
View reviewed changes
Comment thread.github/workflows/schedule.yml
@araujogui
araujogui
commented
Aug 30, 2025

Copy link


Copy Markdown

MemberAuthor
I think it would make sense to create a PR when there is something changed. I wouldn't go redo this because of this suggestion, but you can see a similar workflow in the docker-node repo
Well, that makes sense, but @nodejs/releasers would have to check, approve the pr and merge every Monday (obligatorily).
AugustinMauroy
AugustinMauroy
approved these changes
Aug 30, 2025
View reviewed changes
@AugustinMauroyAugustinMauroy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

LGMT !
ovflowd
ovflowd
approved these changes
Aug 31, 2025
View reviewed changes
@ovflowdovflowd
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

PR looks good to me, but can we get someone from @nodejs/releasers to check this and agree that auto merge is OK?
@targos
targos
commented
Sep 2, 2025•

edited

Loading

Copy link


Copy Markdown

Member
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
@targos
targos
commented
Sep 2, 2025

Copy link


Copy Markdown

Member
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
@araujogui
araujogui
commented
Sep 2, 2025

Copy link


Copy Markdown

MemberAuthor
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Got it, issue fixed. I also pinned package versions
octavio12345300
octavio12345300
approved these changes
Sep 3, 2025
View reviewed changes
@octavio12345300octavio12345300
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

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

listo
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
CC @nodejs/releasers
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual.

How big of a deal is it if this repo is updated manually every once in a while?
@araujogui
araujogui
commented
Sep 8, 2025

Copy link


Copy Markdown

MemberAuthor
I don't think this is worth it, it feels like it's going to be very noisy for little value IMO, and the hard coded version in the npx calls are going to be annoying to maintain. IMO the current process is better, despite being manual. How big of a deal is it if this repo is updated manually every once in a while?
I don't see any problem, but if anyone don't update the SVG in a while, the website will start displaying misleading info
@aduh95
aduh95
commented
Sep 8, 2025

Copy link


Copy Markdown

Contributor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
@araujogui
araujogui
commented
Sep 9, 2025•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
@ovflowd
ovflowd
commented
Sep 10, 2025

Copy link


Copy Markdown

Member
the website will start displaying misleading info
The website can (should) generate its own SVG, there's no reason to use the one in this repo
what do you think @nodejs/nodejs-website? any concerns?
I don't see the value of repeating this process on the Node.js website. There's value on this being here IMO
@ovflowd
ovflowd
commented
Nov 26, 2025

Copy link


Copy Markdown

Member
@nodejs/releasers this PR has staled, what can we do to unblock it, or are we not willing to approve it? Just asking to see if there's anything I can help to unblock it, otherwise we can close the PR if the changeset is not desired.
@aduh95
aduh95
commented
Nov 27, 2025

Copy link


Copy Markdown

Contributor
My feedback from three months ago still stands. I would add that it's unrealistic IMO to assume the automatic PRs would get reviewed, approved, and merged in a timely manner in this repo.
@richardlau
richardlau
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
There's little to no benefit for the Release WG to have the svg update automatically/regularly.
The original reason for this PR was updating the website, but since the recent Release WG session collab summit session I've reinforced my opinion that the graphical view of the release schedule should look different for internal (e.g. Release WG and collaborators) users and ecosystem (e.g. website users) and since the website was refocussed some time ago for users that would suggest to me that the website should have its own release schedule chart.

e.g. We should not make a distinction between "active" and "maintenance" LTS on the public website as that's an operational distinction for the project and is otherwise confusing for users.
I'd even go as far as to suggest that for the Release WG we could get rid of the pre-rendered SVG and instead represent the graphical view in mermaid flavoured markdown, e.g. https://gist.github.com/richardlau/c4a1cc362bff95777917ded762742b2c for a PoC.
Any arguments about having a single source of truth are moot, because the single source of truth for the release schedule is the release.json file, not the svg image.
@ovflowd
ovflowd
commented
Nov 27, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
@ovflowd
ovflowd
commented
Dec 25, 2025

Copy link


Copy Markdown

Member
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.
Bump, @araujogui
@araujoguiaraujogui
mentioned this pull request
Jan 9, 2026
 Merged

@araujoguiaraujogui
mentioned this pull request
Jan 17, 2026
 Open

5 tasks
@ovflowd
ovflowd
commented
Jan 17, 2026

Copy link


Copy Markdown

Member
@araujogui this PR can be closed btw.
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


6 more reviewers

@ovflowdovflowdovflowd approved these changes
@aymen94aymen94aymen94 approved these changes
@AugustinMauroyAugustinMauroyAugustinMauroy approved these changes
@octavio12345300octavio12345300octavio12345300 approved these changes
@scutuatua-cryptoscutuatua-cryptoscutuatua-crypto approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

10 participants

@araujogui@nschonni@targos@aduh95@ovflowd@richardlau@aymen94@AugustinMauroy@octavio12345300@scutuatua-crypto