Release schedule proposal

enhancements/proposed/20200316-release-schedule/schedule-proposal.md

@@ -0,0 +1,56 @@
+# Release Schedule
+
+* First proposed: 2020-03-30
+* Authors: Thomas Stromberg (@tstromberg)
+
+## Reviewer Priorities
+
+Please review this proposal with the following priorities:
+
+* Does this fit with minikube's [principles](https://minikube.sigs.k8s.io/docs/concepts/principles/)?
+* Are there other approaches to consider?
+* Could the implementation be made simpler?
+* Are there usability, reliability, or technical debt concerns?
+
+Please leave the above text in your proposal as instructions to the reader.
+
+## Summary
+
+Adding structure to the release process to encourage predictable stress-free releases with fewer regressions.
+
+## Goals
+
+* A decrease in release regressions
+* Minimal disruption to development velocity
+* Compatible with the upstream Kubernetes release schedule
+
+## Non-Goals
+
+* Maintaining release branches
+
+## Design Details
+
+minikube currently has 3 types of releases:
+
+* Feature release (v1.9.0)
+* Bugfix release (v1.9.1)
+* Beta releases
+
+This proposal maintains the pre-existing structure, but adds dates for when each step will occur:
+
+* Day 0: Create milestones for the next regression & feature release
+* Day 7: Regression release (optional)
+* Day 14: Early Beta release (optional)
+* Day 21: Beta release
+* Day 24: Feature freeze and optional final beta
+* Day 28: Feature release
+
+To synchronize with Kubernetes release schedule (Tuesday afternoon PST), minikube releases should be Wednesday morning (PST). To select a final release date, consult [sig-release](https://github.com/kubernetes/sig-release/tree/master/releases) to see if there is an upcoming minor release of Kubernetes within the next 6 weeks. If so, schedule the minikube release to occur within 24 hours of it.
+
+Even with this schedule, it is assumed that release dates may slip.
+
+## Alternatives Considered
+
+### Release branches
+
+Rather than considering master to always be in a releasable state, we could maintain long-lived release branches. This adds a lot of overhead to the release manager, as they have to manage cherry-picks.