|
| 1 | +# Node.js Release WorkGroup Meeting 2025-07-24 |
| 2 | + |
| 3 | +## Links |
| 4 | + |
| 5 | +* **Recording**: https://youtu.be/jjqi6HTSY4s |
| 6 | +* **GitHub Issue**: https://github.com/nodejs/Release/issues/1114 |
| 7 | +* **Minutes Google Doc**: https://docs.google.com/document/d/1QWNbCnCj-MKfg3z2A2Jz1oNDF4CQVjMAYrPLJCdyFYE |
| 8 | + |
| 9 | +## Present |
| 10 | + |
| 11 | +* Antoine du Hamel @aduh95 |
| 12 | +* Marco @marco-ippolito |
| 13 | +* Michaël Zasso @targos |
| 14 | +* Ruy Adorno @ruyadorno |
| 15 | +* Rafael Gonzaga @RafaelGSS |
| 16 | +* Richard Lau @richadlau |
| 17 | + |
| 18 | +## Agenda |
| 19 | + |
| 20 | +## Announcements |
| 21 | + |
| 22 | +*Extracted from **Release-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. |
| 23 | + |
| 24 | +* Node.js releases will be delayed due to the OSX cluster upgrade |
| 25 | + |
| 26 | +### nodejs/Release |
| 27 | + |
| 28 | +* doc: update the instruction on how to verify releases [#59113](https://github.com/nodejs/node/pull/59113) |
| 29 | + * Antoine: recently lost access to their release keys, problem was openpgp only allows one key per email address, there seems to be consensus on supporting our own keyring, we can use automation to guarantee its contents. Are there any objections? |
| 30 | + * Richard: some background, originally we used a different key server but we ended up switching to multiple ones but openpgp is the one that ended up mentioned in our README files, eventually we started the release-keys repo and the goal was for it to eventually be the source of truth |
| 31 | + * Rafael: adding the notable-change to surface to all users that this should now be the way to validate release key signatures |
| 32 | + * Antoine: maybe we should use certification revocations to be able to revoke one of our keys when we need it |
| 33 | + * Richard: now that we have a differentiation between all keys and the active keys, at least we should be able to revoke a key from the active ones |
| 34 | + * Antoine: could we change the signature on a previous release? |
| 35 | + * Richard: we don’t really have a mechanism for that |
| 36 | + * Richard: signature validation is tied to a specific point in time, whenever you’re validating a key signature it means it was valid at that point in time, one of the problems is that most people don’t treat it signature validation that way |
| 37 | + |
| 38 | +* Schedule downtime for OSX cluster upgrade [#1106](https://github.com/nodejs/Release/issues/1106) |
| 39 | + * Richard: we have an open issue in the build repo about updating the macos vms, we need to update all versions of orca which is the macos vm mechanism from macstadium, the upgrade happened but the vms we had failed to redeploy so for the moment macos is disabled |
| 40 | + * Richard: it also means macos is blocked on the release job in jenkins, so we can’t publish releases at the moment |
| 41 | + * Richard: need to reach out to Ryan to figure out where the state of that work is |
| 42 | + |
| 43 | +* Release plan - v24.x Current [#1089](https://github.com/nodejs/Release/issues/1089) |
| 44 | + * Antoine: pushed some updates to the staging branch but there is no way to run the CI tests |
| 45 | + * Antoine: getting the CI green might be a challenge and having to work through it again when macos is reenabled is going to be extra work |
| 46 | + |
| 47 | +* Release plan - v22.x Active LTS [#1001](https://github.com/nodejs/Release/issues/1001) |
| 48 | + * Antoine: similar to v24.x, currently blocked from running CI |
| 49 | + |
| 50 | +* Release plan - v20.x Maintenance LTS [#855](https://github.com/nodejs/Release/issues/855) |
| 51 | + * Marco: planning to release around August, can volunteer to release on the second half of the month and hopefully the macos update story has been fixed by then |
| 52 | + |
| 53 | +* Proposal - Shift Node.js to Annual Major Releases and Shorten LTS Duration #1113 |
| 54 | +* Proposal for new release schedule / users are not interested in releases that will not become LTS [#953](https://github.com/nodejs/Release/issues/953) |
| 55 | + * Rafael: nobody seems to be opposed to having just one major release a year, needs some discussion on how that impacts enterprise vs community |
| 56 | + * Rafael: at least one release a year seems ok, now we’re discussing the frequency of the different variations, James proposed a model in which we release a new major every year but only one of them is LTS, keeping the even vs odd numbers distinction |
| 57 | + * Ruy: I know Antoine worked on a graph render of James proposal but I think it was a bit off |
| 58 | + * Antoine: having only a major release every year brings up the problem that was mentioned in the discussion yesterday of taking too long to introduce breaking-changes to the end users |
| 59 | + * Rafael: |
| 60 | + * Marco: one of the benefits of having one release per year, we can always cut beta releases for package maintainers to replace the odd-versions intent, supporting a version for 3 years is a maintenance burden |
| 61 | + * Ruy: there seems to be a lot of pushback against the idea of prereleases, from the discussion yesterday many folks mentioned that the current release line serves that goal much better |
| 62 | + * Richard: even if we switch to the prereleases there’s still all the extra work of merging commits into the staging branch so it’s not really saving that much work |
| 63 | + * Rafael: one requirement that was a takeaway from yesterday’s discussion is that the releases needs to be predictable, with a well structured schedule, it doesn’t mean we can’t change it at this point in time but it needs to remain predictable from now on |
| 64 | + * Rafael: we should focus on discussing the details of the proposal, either on a new PR / issue or updating the description in the current one |
| 65 | + * Antoine: maybe we should start by discussing if we really want an alpha / beta channel |
| 66 | + * Rafael: how does it work? |
| 67 | + * Antoine: alpha should just include all commits from main at that point in time, same with current releases but with breaking-changes from time to time |
| 68 | + * Rafael: |
| 69 | + * Michael: my idea for the alpha is to cut release from the main branch |
| 70 | + * Antoine: that’s viable but that way we can’t have security releases |
| 71 | + * Michael: that’s fine since we could set a policy of not having security release for prereleases |
| 72 | + * Rafael: why can’t we cut security releases? |
| 73 | + * Michael: we would have to lock the main branch in order to make that work, so that we can cherry-pick specific commits from the private repo without conflicts |
| 74 | + * Rafael: let’s maybe come up with a few proposals on the actual implementation of prereleases, there seems to be agreement that they can work |
| 75 | + * Ruy: from yesterday conversation there seems to be a lot of pushback agains the ideas of prerelease, mostly that package authors are much better served by the current release line and wouldn’t be adopting prereleases |
| 76 | + * Richard: enterprise won’t ever touch current release lines, they really only care about LTS |
| 77 | + * Ruy: one of the arguments is that package authors won’t adopt prereleases vs current |
| 78 | + * Michael: as a package author, I disagree, I maintain hundreds of packages and I would be testing against prereleases |
| 79 | + * Rafael: prerelease lines would serve much better the purpose of nightly builds, which are really just completely ignored by the community at this point in time |
| 80 | + * Antoine: agree with the feedback from the TSC call that some authors will not adopt the prerelease lines but there are also authors that will adopt and benefit more from the most often updates |
| 81 | + * Richard: it depends a lot how we treat the API surface and what is a breaking change or not in these prerelease lines |
| 82 | + * Michael: if we have to keep ABI stability that means we can’t update v8 anymore |
| 83 | + * Rafael: are v8 updates all considered semver-major? |
| 84 | + * Michael: not necessarily, but c++ changes in v8 are considered semver-major and those happen all the time |
| 85 | + * Antoine: we could guarantee ABI stability with the exception of just right before cutting the new major x.0.0 release |
| 86 | + * Michael: just unsure how addons developers would handle that |
| 87 | + * Antoine: could the next-10 team help with that with a survey? |
| 88 | + * Marco: yes, it’s definitely a question we could add to our survey, just needs to validate with the foundation which helps to run the survey |
| 89 | + * Rafael: maybe it’s not a reliable source but we could also open community polls in social media |
| 90 | + * Ruy: not sure about social media polling as it might be too distorted |
| 91 | + * Antoine: who could we talk to to present the plan to see if it would work? Having ABI instability in the middle of a release line |
| 92 | + * Ruy: maybe the best we can get is the survey? What are the specific consumers? |
| 93 | + * Antoine: Add-on developers |
| 94 | + * Ruy: maybe the best thing is to reach out directly to these folks and ask for feedback |
| 95 | + |
| 96 | +## Q&A, Other |
| 97 | + |
| 98 | +## Upcoming Meetings |
| 99 | + |
| 100 | +* **Node.js Project Calendar**: <https://nodejs.org/calendar> |
| 101 | + |
| 102 | +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. |
| 103 | + |
| 104 | + |
0 commit comments