suggestion: that nodejs release information be moved to nodejs/node

[sam-github]

Information about Node.js release process is spread across two github repos in way that is starting to appear arbitrary.

I think the current situation arose naturally from the history. The LTS team was originally somewhat seperate from the "current releases" team. It was tasked with making a proposal for an LTS support plan, and the plan was developed and implemented in the WG repo, and has remained here ever since.

But now that years have gone by and the plan has moved from proposal to routine, that the LTS policy and schedule isn't in the main nodejs/node repo makes it hard to find.

I was specifically reminded about this again recently by nodejs/node#30471 (comment)

I suggest:

• https://github.com/nodejs/Release#release-schedule is important, it should be in the nodejs/node top-level README
• ditto for https://github.com/nodejs/Release#end-of-life-releases
• https://github.com/nodejs/Release#mandate is this WG's policy, it should remain where it is
• https://github.com/nodejs/Release#release-plan should be in https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md
• https://github.com/nodejs/Release#marking-a-release-line-as-lts is the kind of information that is mostly in https://github.com/nodejs/node/tree/master/doc/guides for the other maintenance tasks, but maybe having here is ok, its this WG that uses the information.
• https://github.com/nodejs/Release#lts-staging-branches should be in the https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md, collaborators should understand the branch structure of their project

Thoughts?

cc: @nodejs/collaborators

[keywordnew]

I'm not as well-versed with the problem as I'd like to be. But I would still add that if information from nodejs/Release is moved elsewhere, those mentions should be tracked in nodejs/Release.

The references being tracked from one source will make it easier for the WG to keep them all current (and be aware of changes being made to them) even if they don't live in this repo any more.

[mhdawson]

I can see that some of the info would be more discoverable in the main node repo. I think all of those @sam-github suggest be moved make sense to move.

[MylesBorins]

I'm not sure I'm keen on the idea.

The @nodejs/release team owns this process, and there would be risk that if it lived in the nodejs/node repo that it could be changed without review from the team.

Making more obvious references to it in the nodejs/node repo could definitely help though.

To be clear I'm currently closer to -0 than -1... need to think on this more

I've added to the agenda so we can discuss at the next meeting

[sam-github]

Please do take a look through and see what you all are comfortable moving. Most people's interaction with the project is actually through release consumption... the information about the release process is pretty core to the project.

I don't think the release policy docs would be unique in being nodejs/node, but owned by working groups. https://github.com/nodejs/node/blob/master/BUILDING.md is in the same category. I'm not sure it has an official "owned by build and release WGs" warning, but I don't recall any attempts to change it by people not involved in the relevant WGs.

If someone did get a change in to the release process by some accident, it wouldn't actually change what you do, and it would get reverted pretty quickly, I think!

[boneskull]

could we use CODEOWNERS to help with this somehow?

[Trott]

If we do move the release schedule, we'll need to update the nodejs.org repo so that https://nodejs.org/en/about/releases/ (and any translations) get the image from the new location.

[MylesBorins]

could we use CODEOWNERS to help with this somehow?

Unfortunately I don't think so. We are talking about taking the policy and spreading it across multiple docs that have various owners. Release would only own a section of the doc and as such I am unsure of a way to automate needing appropraite review.

Most people's interaction with the project is actually through release consumption... the information about the release process is pretty core to the project.

I would like to challenge this premise. While many folks do engage with the project through release consumption I would assume that most folks looking for documentation / information are going to the website. As it already is finding information within the repo is hard... the governance is spread across a bunch of different markdown files.. and even as someone who has helped draft some of it I often struggle to remember where to look.

I do not think that moving this to the main repo increases visibility any more than include better pointers to the release docs. The current proposal involves splitting the information which is currently centralized into a variety of already quite dense documents

One alternative would be putting everything in a single top-level markdown file within the nodejs/node repo... but I'm not 100% this is going to be significantly better then simply including a pointer to this repo.

One other thing to keep in mind, our documentation between releases does not always stay up to date. If you look at 10.x or 12.x the contributor guides are not necessarily up to date. Moving this information rather then having a pointer and keeping it centralized significantly increases the chance of folks getting stale information (such as an out of date release schedule).

Honestly I'm starting to lean more towards -1... but I won't be a lone objector here. Do folks disagree with my assessment?

[richardlau]

I would prefer to keep the release schedule and chart in this repository as I'm aware there is stuff that uses/links to it (but 👍 to adding links to it from the main Readme in core). Policy should probably be kept here too to avoid duplication (anything in core has multiple versions in each release line as @MylesBorins points out).

I am open to moving anything that is the mechanics of doing releases (e.g. the Marking a Release Line As LTS in the readme) as the bulk of that documentation is already in core in the Release process.

Bear in mind there are different sorts of users who want to reference the information, not all of whom would look at the core nodejs/node repository as a first point of reference (for example I know some people go to the website to look for the release schedule which now pulls information from this repository and points back to it).

[targos]

I agree with Myles.
FWIW, searching for "node.js release" on Google and DuckDuckGo gives this repo in one of the first results, even before nodejs/node.