mirror of
https://github.com/golang/go.git
synced 2025-05-05 15:43:04 +00:00
Destroyed Go Release Cycle (markdown)
1132zzx
parent
11382b6b2a
commit
facce8a041
@ -1,174 +0,0 @@
|
|||||||
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…
x
Reference in New Issue
Block a user