Move to time based releases and update LTS #7

dmcgowan · 2025-01-18T01:07:57Z

Adds new criteria and schedule for time based releases. Adds more ownership and roles for the different phases of the release process.

Updates LTS definition and schedule

samuelkarp · 2025-01-18T01:12:21Z

RELEASES.md

+For example, 1.0.0 to 1.2.0 is not supported. One should first upgrade to 1.1,
+then 1.2.
+
+There are no compatibility guarantees with upgrades to _major_ versions. For


This should probably be updated to discuss the upgrade path from 1.7.x to 2.0.x.

We don't need to make it a part of this change, but we also need to cover LTS upgrades; i.e., can you upgrade directly from one LTS to the next?

Yeah, we should revisit this section

RELEASES.md

AkihiroSuda · 2025-01-20T04:28:24Z

RELEASES.md

-guarantees are provided.
+The maintainers will maintain a roadmap and milestones for each release, however,
+features may be pushed to accomodate the release timeline. If your issue or feature
+is not present in the roadmap, please reach out to the maintainers or leave a


Suggested change

is not present in the roadmap, please reach out to the maintainers or leave a

is not present in the roadmap, please open a GitHub issue

AkihiroSuda · 2025-01-20T04:30:49Z

RELEASES.md

-issue or PR is not present in a milestone, please reach out to the maintainers
-to create the milestone or add an issue or PR to an existing milestone.
+While pre-releases are done to assist in the stabilization process, no quality
+guarantees are provided.


Maybe remove this sentence, as no "guarantee" is provided for any release

AkihiroSuda · 2025-01-20T04:31:52Z

RELEASES.md

-> extended support, it will continue to accept security patches in addition to client
-> changes relevant for package importers using the 1.6 LTS daemon.
+Long term stable (_LTS_) releases are sponsored by at least two maintainers for at least two
+years after their initial _minor_ release. The maintainers of the _LTS_ branch may commit to a


"initial minor release" is .0 or .1?

Updated to mention x.y.0

AkihiroSuda · 2025-01-20T04:34:11Z

RELEASES.md

+are both active maintainers and one of which has been involved in two prior releases.
+
+Once the final release is out and the release branch moves to active, ownership will be
+transferred back over to all maintainers. Active releases are maintained by all maintainers


s/maintainers/Committers/g

AkihiroSuda · 2025-01-20T04:39:10Z

RELEASES.md

-from their source branch. For major and minor releases, these releases will be
-done from main. For patch releases, these pre-releases should be done within
-the corresponding release branch.
+Minor releases are time based with a target cadence of 6 months. The next two


Maybe this cadence should be marked tentative until 2026.
We have to have a couple of releases to evaluate whether this plan is feasible in practice

I updated from "target cadence" to "initial cadence". I think the following sentence makes it clear that the cadence is open to change, let me know if that is not clear though

AkihiroSuda · 2025-01-20T04:49:02Z

RELEASES.md

+releases to support the longer term maintainability of the branch, including library dependency,
+toolchain (including Go) and other version updates which are needed to ensure each release is built
+with fully supported dependencies. Feature backports are up to the discretion of the maintainers who
+own the branch but should be rejected by default. There is no limit to the number of _LTS_ branches


Probably a soft-limit can be set.
It doesn't sound realistic to keep maintaining more than 3 LTS branches

Updated to say "no defined limit", we can define a limit if needed in the future

fuweid · 2025-01-20T21:40:14Z

RELEASES.md

-> by Go modules, 1.7 must be supported until EOL of all 1.x releases. Once 1.7 is in
-> extended support, it will continue to accept security patches in addition to client
-> changes relevant for package importers using the 1.6 LTS daemon.
+Long term stable (_LTS_) releases are sponsored by at least two maintainers for at least two


Do we need a file to track who the sponsor of the LTS is?

This file should be the source of truth

fuweid · 2025-01-20T21:44:43Z

RELEASES.md

+ownership transferred back to all committers.
+
+
+### All Releases


maybe we should add column for LTS's sponsor?

Thats what the owners field is intended for

mikebrow

a few proposed changes

RELEASES.md

mikebrow · 2025-01-21T19:52:42Z

RELEASES.md

+- __*Future*__: An upcoming scheduled release.
+- __*Alpha*__: The next scheduled release on the main branch under active development.
+- __*Beta*__: The next scheduled release on the main branch under testing. Begins 8-10 weeks before a final release.
+- __*RC*__: The next scheduled release on the main branch under final testing and stabilization. Begins 2-4 weeks before a final release. For new releases where the source branch is main, the main branch will be in a feature freeze during this phase.
 - __*Active*__: The release is a stable branch which is currently supported and accepting patches.
 - __*Extended*__: The release branch is only accepting security patches.


Suggested change

- __*Extended*__: The release branch is only accepting security patches.

- __*Extended*__: The release branch is only accepting security patches any other critical updates would require formal exception approval at the discretion of the committers.

Updated to say "and critical updates", up the discretion of the owners has to always be applied I think. Applying something "critical" shouldn't have be an exception, only defining what is "critical"

RELEASES.md

Signed-off-by: Derek McGowan <[email protected]>

samuelkarp · 2025-01-21T23:09:47Z

RELEASES.md

+on the current release cadence. Any changes to the release cadence will avoid
+impacting releases which are already scheduled.


Suggested change

on the current release cadence. Any changes to the release cadence will avoid

impacting releases which are already scheduled.

on the current release cadence. Changes to the release cadence will not

impact releases which are already scheduled.

samuelkarp · 2025-01-22T00:07:45Z

RELEASES.md

+### Release Owners
+
+Every release shall be assigned owners when entering into the beta stage of the release. The initial
+release owners will act as the release captains and will be responsible for creating the releases and


We should either define or omit the term "release captains". I think it's clear enough without including that; the owners are responsible for doing these things.

samuelkarp · 2025-01-22T00:08:57Z

RELEASES.md

+release owners will act as the release captains and will be responsible for creating the releases and
+ensuring the release is on time. Once the release is in rc, the release owners should be part of any
+discussion around merging impactful or risky changes. Every release should have two owners who
+are both active maintainers and one of which has been involved in at least two prior releases.


What are the "involved in" requirements? Does that just mean "a maintainer during the Active state of that release" or acting in some other capacity?

I'll update to has been a release owner to make it more explicit. The idea is that it would allow non-committers to be involved with releases. We can leave it up to us how we would define release owners for prior releases, but I plan to be involved in the next two scheduled releases to help transition the process anyway. I can update to "at least" two if that will help train more folks if necessary.

Adds new criteria and schedule for time based releases. Adds more ownership and roles for the different phases of the release process. Signed-off-by: Derek McGowan <[email protected]>

Signed-off-by: Derek McGowan <[email protected]>

samuelkarp reviewed Jan 18, 2025

View reviewed changes

dmcgowan force-pushed the new-release-schedule branch from e3b8b90 to 7a80402 Compare January 20, 2025 00:41

AkihiroSuda reviewed Jan 20, 2025

View reviewed changes

dmcgowan force-pushed the new-release-schedule branch 2 times, most recently from 9f2a200 to 84f7bc5 Compare January 20, 2025 07:12

fuweid reviewed Jan 20, 2025

View reviewed changes

mikebrow reviewed Jan 21, 2025

View reviewed changes

Update LTS definition and support horizon

886d971

Signed-off-by: Derek McGowan <[email protected]>

dmcgowan force-pushed the new-release-schedule branch from 84f7bc5 to a3cad56 Compare January 21, 2025 22:19

samuelkarp reviewed Jan 22, 2025

View reviewed changes

dmcgowan force-pushed the new-release-schedule branch 3 times, most recently from d0a53f4 to d8262af Compare January 22, 2025 06:31

dmcgowan added 2 commits January 22, 2025 07:34

Update to time based releases

d08fa7d

Adds new criteria and schedule for time based releases. Adds more ownership and roles for the different phases of the release process. Signed-off-by: Derek McGowan <[email protected]>

Update upgrade section

1fc48b9

Signed-off-by: Derek McGowan <[email protected]>

dmcgowan force-pushed the new-release-schedule branch from d8262af to 1fc48b9 Compare January 22, 2025 15:44

dmcgowan closed this Jan 22, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move to time based releases and update LTS #7

Move to time based releases and update LTS #7

dmcgowan commented Jan 18, 2025

samuelkarp Jan 18, 2025

dmcgowan Jan 18, 2025

AkihiroSuda Jan 20, 2025

AkihiroSuda Jan 20, 2025

AkihiroSuda Jan 20, 2025

dmcgowan Jan 20, 2025

AkihiroSuda Jan 20, 2025

AkihiroSuda Jan 20, 2025

dmcgowan Jan 20, 2025

AkihiroSuda Jan 20, 2025

dmcgowan Jan 20, 2025

fuweid Jan 20, 2025

dmcgowan Jan 21, 2025

fuweid Jan 20, 2025

dmcgowan Jan 21, 2025

mikebrow left a comment

mikebrow Jan 21, 2025

dmcgowan Jan 21, 2025

samuelkarp Jan 21, 2025

samuelkarp Jan 22, 2025

samuelkarp Jan 22, 2025

dmcgowan Jan 22, 2025

	is not present in the roadmap, please reach out to the maintainers or leave a
	is not present in the roadmap, please open a GitHub issue

		ownership transferred back to all committers.


		### All Releases

	- __Extended__: The release branch is only accepting security patches.
	- __Extended__: The release branch is only accepting security patches any other critical updates would require formal exception approval at the discretion of the committers.

		on the current release cadence. Any changes to the release cadence will avoid
		impacting releases which are already scheduled.

Move to time based releases and update LTS #7

Move to time based releases and update LTS #7

Conversation

dmcgowan commented Jan 18, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikebrow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment