enhancements/proposed/20200316-release-schedule/schedule-proposal.md
Please review this proposal with the following priorities:
Please leave the above text in your proposal as instructions to the reader.
Adding structure to the release process to encourage predictable stress-free releases with fewer regressions.
minikube currently has 3 types of releases:
This proposal maintains the pre-existing structure, but adds dates for when each step will occur:
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 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.
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.
As this process assumes a regression release at Day 7, it begs the question on whether or not a 5-week feature release cycle makes more sense:
The downside is a slightly lower release velocity, the upside may be more a more stable final release.