mirror of
https://github.com/golang/go.git
synced 2024-11-22 05:40:42 +00:00
Revert 11382b6b2a967c678c7880fef12ea31e9e47a745...facce8a041841e2584ad4ef2f8f47eca83ca7eff
Matt Layher
parent
facce8a041
commit
90f8c51719
174
Go-Release-Cycle.md
Normal file
174
Go-Release-Cycle.md
Normal file
@ -0,0 +1,174 @@
|
||||
This wiki page is maintained by the Go team. Please
|
||||
[send comments to golang-dev](https://groups.google.com/group/golang-dev) or
|
||||
[file issues](https://go.dev/issue) instead of making changes directly.
|
||||
|
||||
Short link: https://go.dev/s/release.
|
||||
|
||||
## Overview
|
||||
|
||||
Go is released every six months. Each release cycle is broken down into a
|
||||
development phase lasting about 4 months, followed by a 3-month period of
|
||||
testing and polishing called the release freeze. If everything goes well, work
|
||||
on the next release begins before the previous release has shipped, resulting in
|
||||
an overlap of about a month.
|
||||
|
||||
After the initial release of a version, it is supported with minor releases that
|
||||
fix severe bugs and security issues.
|
||||
|
||||
## Timeline
|
||||
|
||||
The current release cycle is aligned to start in mid-January and mid-July of
|
||||
each year. The target milestones for a release cycle are as described below. We
|
||||
try to hit the targets as closely as possible, while still delivering a quality
|
||||
release.
|
||||
|
||||
To give the team time to prepare, and to address unexpected problems, we prefer
|
||||
to do release work early or mid-week. That means that exact dates will vary year
|
||||
to year, so milestones are specified as weeks in a particular month. Week 1 is
|
||||
the week starting on the first Monday of the month. All dates are subject to
|
||||
change based on the year's holiday timings.
|
||||
|
||||
|
||||
|
||||
#### January / July week 1: Planning for release begins.
|
||||
|
||||
Planning of major work for upcoming release cycle is announced on
|
||||
[golang-dev](https://groups.google.com/group/golang-dev).
|
||||
|
||||
Example: [Go 1.20](https://groups.google.com/g/golang-dev/c/V8ez4YunkeE)
|
||||
|
||||
#### January / July week 3: Release work begins.
|
||||
|
||||
Once the prior release has entered its final stabilization period, the tree
|
||||
opens for general development. All kinds of development are welcome during this
|
||||
period. It's preferable for large or particularly risky changes to land well
|
||||
before the end of the development window, so that there's time to fix any
|
||||
problems that arise with them.
|
||||
|
||||
#### May / November week 4: Release freeze begins.
|
||||
|
||||
This milestone begins the second part of the release cycle, the release freeze.
|
||||
The release freeze applies to the entire main repository as well as to the code
|
||||
in subrepositories that is needed to build the binaries included in the release,
|
||||
particularly vet and all its dependencies in the tools subrepository.
|
||||
|
||||
During the freeze, only bug fixes and doc updates are accepted. On occasion new
|
||||
work may be done during the freeze, but only in exceptional circumstances and
|
||||
typically only if the work was proposed and approved before the cutoff. Such
|
||||
changes must be low risk. See [freeze exceptions](#freeze-exceptions) below.
|
||||
|
||||
This part of the release cycle is focused on improving the quality of the
|
||||
release, by testing it and fixing bugs that are found. However, every fix must
|
||||
be evaluated to balance the benefit of a possible fix against the cost of now
|
||||
having not as well tested code (the fix) in the release. Early in the release
|
||||
cycle, the balance tends toward accepting a fix. Late in the release cycle, the
|
||||
balance tends toward rejecting a fix, unless a case can be made that the fix is
|
||||
both low risk and high reward.
|
||||
|
||||
Examples of low risk changes appropriate late in the cycle include changes to
|
||||
documentation and fixes to new features being introduced in the current release
|
||||
(since there is no chance of introducing a regression compared to an earlier
|
||||
release).
|
||||
|
||||
Shortly after the freeze begins, nearly all known bugs should have been fixed or
|
||||
explicitly postponed (either to the next release or indefinitely). The remainder
|
||||
should usually be tracked as release blockers and worked on urgently.
|
||||
|
||||
#### June / December week 2: Release candidate 1 issued.
|
||||
|
||||
A release candidate is meant to be as close as possible to the actual release
|
||||
bits. Issuing a release candidate is an indication that the Go team has high
|
||||
confidence that the tree is free of critical bugs. In particular, because Google
|
||||
continuously tracks the development version of Go, by the time a release
|
||||
candidate is issued, a close approximation of it will have been running in
|
||||
production at Google for at least a week or two.
|
||||
|
||||
Once a release candidate is issued, only documentation changes and changes to
|
||||
address critical bugs should be made. In general the bar for bug fixes at this
|
||||
point is even slightly higher than the bar for bug fixes in a minor release. We
|
||||
may prefer to issue a release with a known but very rare crash than to issue a
|
||||
release with a new but not production-tested fix.
|
||||
|
||||
If critical bugs are reported and fixed, additional release candidates may be
|
||||
issued, but typically not more than one every two weeks.
|
||||
|
||||
Again, a release candidate is meant to be bug-free, as much as possible.
|
||||
Organizations are encouraged to deploy it in production settings after
|
||||
appropriate organization-specific testing.
|
||||
|
||||
The calm period between a release candidate and the final release is a good time
|
||||
for additional testing or for discussing the next release (see the planning
|
||||
milestone above).
|
||||
|
||||
#### July / January week 3: Work on the next release begins
|
||||
|
||||
While the current release is being stabilized, the tree reopens for work on the
|
||||
next. During this period, fixes intended for the current release need to be
|
||||
[cherry-picked onto the release branch](https://go.dev/wiki/MinorReleases#making-cherry-pick-cls).
|
||||
Unlike cherry-picks for minor releases, these changes don't need a backport
|
||||
issue and don't need to be approved by the release team. As long as they're
|
||||
permitted by the [freeze policy](#may--november-week-4-release-freeze-begins),
|
||||
they can be reviewed and submitted like any other CL.
|
||||
|
||||
#### August / February week 2: Release issued.
|
||||
|
||||
Finally, the release itself!
|
||||
|
||||
A release should not contain significant changes since the last release
|
||||
candidate: it is important that all code in the release has been well tested.
|
||||
Issuing a release is an indication that release testing has confirmed the
|
||||
release candidate's high confidence that the tree is free of critical bugs.
|
||||
|
||||
Even if a release goes smoothly and there's spare time, we prefer to stay on
|
||||
schedule. Extra testing can only improve the stability of a release, and it also
|
||||
gives developers working on the Go release more time to think about and plan the
|
||||
next release before code changes start pouring in again.
|
||||
|
||||
By the time of the final release, Google will have been using this version of Go
|
||||
for nearly two months. While Google's successful use does not guarantee the
|
||||
absence of problems, our experience has been that it certainly helps improve the
|
||||
quality of the release. We strongly encourage other organizations to test
|
||||
release candidates as aggressively as they are able and to report problems that
|
||||
they find.
|
||||
|
||||
Once a release is stabilized, work on the next release, including code reviews
|
||||
and submission of new code, can begin, and the cycle repeats. Note that if a
|
||||
release is delayed, work on the next release may be delayed as well.
|
||||
|
||||
## Release Maintenance
|
||||
|
||||
A minor release is issued to address one or more critical problems for which
|
||||
there is no workaround (typically related to stability or security). The only
|
||||
code changes included in the release are the fixes for the specific critical
|
||||
problems. Important documentation-only changes and safe test updates (such as
|
||||
disabling tests), may also be included as well, but nothing more. Minor releases
|
||||
preserve backwards compatibility as much as possible, and don't introduce new
|
||||
APIs.
|
||||
|
||||
Minor releases to address problems (including security issues) for Go 1.x stop
|
||||
once Go 1.x+2 is released. For more about security updates, see the
|
||||
[security policy](https://go.dev/security).
|
||||
|
||||
See also the [MinorReleases](https://go.dev/wiki/MinorReleases) wiki page.
|
||||
|
||||
## Freeze Exceptions
|
||||
|
||||
Fix CLs that are
|
||||
[permitted by the freeze policy](#may--november-week-4-release-freeze-begins) do
|
||||
not need a freeze exception.
|
||||
|
||||
Any exceptions to the freeze must be communicated to and explicitly approved by
|
||||
the Go Release Team before the freeze. If you’d like to request an exception,
|
||||
please file an issue in the issue tracker with "[freeze exception]" as a suffix
|
||||
and include "CC @golang/release" ([example](https://go.dev/issue/42747)). We
|
||||
will address any requests on a case-by-case basis with a strong preference for
|
||||
not permitting changes after the freeze.
|
||||
|
||||
## Historical note
|
||||
|
||||
A version of this schedule, with a shorter development window, was originally
|
||||
adopted for the Go 1.7 release in 2016. After years of difficult releases,
|
||||
testing and process improvements in 2022 and 2023 led to a timely 1.19 release.
|
||||
For 1.20, the development window was expanded with a late freeze and early thaw.
|
||||
These changes were formalized for the 1.21 release. We anticipate continuing to
|
||||
ship on time.
|
||||
Loading…
Reference in New Issue
Block a user