Code freeze policies w/ releases

kubernetes-sigs / cluster-api

Home for Cluster API, a subproject of sig-cluster-lifecycle

https://cluster-api.sigs.k8s.io

Apache License 2.0

3.5k stars 1.3k forks source link

Code freeze policies w/ releases #2372

Closed vincepri closed 3 years ago

vincepri commented 4 years ago

We should document a timing policy for code freeze. Often times during a cycle we find ourself adding more changes than previously discussed. Let's try and find guidelines that makes sense with our development processes.

/kind documentation

chuckha commented 4 years ago

If we take cues from the latest Kubernetes release, enhancements freeze (must have a proposal in implementable state, must have an open issue in the milestone) is 7 weeks before release followed by code freeze (no more additions to code; only release blocking issues get merged) 3 weeks before release.

We could probably twiddle the timing a bit (5 weeks and 2 weeks perhaps) and relax the enhancements requirements to either CAEP + issue or just issue with 3 +1s from approvers (this is for our light-weight proposal process that is an issue only)

detiber commented 4 years ago

My take is:

move away from date based releases
set a date for feature freeze
based on features desired for next release by feature freeze, set a tentative code complete date.
once all features are in (or bumped) cut an rc release, keep churning on rc release until blocking bugs are 0
only accept bugfixes until release is cut

Work to set next feature freeze and future proposals can go on in parallel to the above process.

Additionally, anything behind an experimental feature gate can likely be allowed to happen independent of the current release cycle, but that is likely a separate discussion.

vincepri commented 4 years ago

/milestone v0.3.x

vincepri commented 4 years ago

From @ncdc in #1949:

We should formally define & document & adhere to a proper release cycle for this project. It doesn't have to be too heavyweight, and could look something like this:

Start of cycle: review all open issues (backlog grooming)
Feature freeze: cutoff date for deciding which features are in/out for the release
Code freeze: cutoff date when all new features should be ready & merged
Something about alpha/beta/RC releases & bug fixes
Release day
I'd love to have advice and guidance from people who have worked on Kubernetes releases to know what we should consider doing (e.g. @justaugustus)

This came out of the v1alpha2 retrospective (#1438)

fabriziopandini commented 4 years ago

+100

vincepri commented 4 years ago

/assign /milestone v0.3.6

vincepri commented 4 years ago

/milestone v0.4.0 /priority critical-urgent

vincepri commented 3 years ago

/close

This has been done

k8s-ci-robot commented 3 years ago

@vincepri: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/2372#issuecomment-706239235): >/close > >This has been done Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.