nodejs
ci: regenerate release svg automatically
Related https://github.com/nodejs/nodejs.org/issues/8101
Create a workflow to automatically re-generate the release schedule SVG weekly.
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
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).
Direct push to main sounds scary, especially since this downloads 3rd-party packages from npm (through npx lts and npx svgo).
Currently the main branch is not protected by rulesets but I think we should change that (breaking the workflow proposed here).
Currently the
mainbranch 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
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 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
npxcalls 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
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
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?
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
@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.
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.
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.
These are really good arguments, given thar, @araujogui I believe we should implement this downstream on the website.