doc: add minutes for meeting 2025-06-26

doc/meetings/2025-06-26.md

@@ -0,0 +1,68 @@
+# Node.js  Release WorkGroup Meeting 2025-06-26
+
+## Links
+
+* **Recording**: https://youtu.be/czGUdi6HNMg
+* **GitHub Issue**: https://github.com/nodejs/Release/issues/1105
+* **Minutes Google Doc**: https://docs.google.com/document/d/1-nRCek1qW-tB4XJKOT9MY48eqOfUEQMQOQq3LfUHzTw/edit?tab=t.0
+
+## Present
+
+* Ruy Adorno: @ruyadorno
+* Rafael Gonzaga: @RafaelGSS
+* Marco Ippolito: @marco-ippolito
+* Richard Lau: @richardlau 
+* Antoine du Hamel: @aduh95 
+
+## Agenda
+
+## Announcements
+  * Rafael: v24.3.0 went out this week
+  * Antoine: v22.17.0 went out this week
+
+### nodejs/Release
+
+* docs: add schedule for Node.js 25 and Node.js 26 [#1095](https://github.com/nodejs/Release/pull/1095)
+  * Antoine: Just reusing the same days as 23 and 22 to start with (not 24 as its initial release was delayed due to V8 update)
+  * Ruy: Landing since it has been opened for 3 weeks
+* Release plan - v24.x Current [#1089](https://github.com/nodejs/Release/issues/1089)
+  * Rafael: Planning to work on the next release but changing the release date to 2025-07-09
+  * Richard: Reminded of the currently planned downtime for infrastructure
+  * Richard: We can suggest to plan that downtime for next week
+* Release plan - v22.x Active LTS [#1001](https://github.com/nodejs/Release/issues/1001)
+  * Antoine: Did the last release 2 days ago
+  * Ruy: We need to find a releaser for the next release
+* Release plan - v20.x Maintenance LTS [#855](https://github.com/nodejs/Release/issues/855)
+  * Marco: Updating the current release plan schedule
+  * Marco: Planning to work on the next v20.x release, likely to be v20.20.0
+  * Marco: Needs to make sure we coordinate in case there’s a security release before that
+* Proposal for new release schedule [#855](https://github.com/nodejs/Release/issues/953)
+  * Rafael: From a certain point of view reducing the frequency of releases make development harder as it makes the feedback loop a lot longer
+  * Rafael: Having 2 major releases per year is hard for companies to keep track of
+  * Rafael: It’s already hard to find volunteers to work on releases, and without support (Alpha Omega), I'm afraid that we'll suffer again from no volunteers for all non-EOL lines
+  * Rafael: Maybe we should shorten the LTS support?
+  * Marco: With a shorter life span for the LTS release lines we can make it easier to handle all release lines in general as the longer the release line is, the hard it is to work on it to create new releases
+  * Antoine: Reducing the lifespan might be better than reducing the number of supported release lines
+  * Rafael: Security releases are also made a lot harder when very old LTS release lines are still around
+  * Richard: The difficulties might also be more related to the nature of semver breaking changes rather than the duration of the release line
+  * Rafael: There are some examples of backports being harder to work on due to old release lines
+  * Richard: We also see people wanting the release lines duration to be longer
+  * Richard: Challenges are more related to semver breakages than the duration or number of supported release lines
+  * Marco: Would like to propose to shorten the LTS release line duration with the goal of having less time in maintenance mode
+  * Antoine: If we were to do that, it’s very important how we communicate that to the broader community
+  * Richard: It seems that having a period of maintenance after current releases is a new concept. Historically only LTS would eventually have a maintenance period.
+  * Richard: One challenge with maintenance releases is backporting important fixes that may be impacted by semver major changes.
+  * Richard: Prefer to not change the length of support of LTS release lines already out
+  * Marco: Automation has made the release work a lot easier
+  * Rafael: Next steps would be to create the proposal and the Release WG can make a decision
+  * Ruy: I would like to read the proposal in detail before making a judgement about it, as mentioned by Richard previously the Release WG is chartered with deciding the release schedule so we’re likely to be able to make that decision within the working group.
+  * Antoine: If someone brings in a concrete proposal we can try and build consensus on it, consulting with other collaborators as part of that if we want to
+  * Ruy: Rafael is to work on the next steps to bring a concrete proposal and this brings us to the end of the agenda
+
+## Upcoming Meetings
+
+* **Node.js Project Calendar**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.
+
+