kubernetes
/
minikube
mirror of https://github.com/kubernetes/minikube.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
minikube/enhancements/proposed/20200316-release-schedule/schedule-proposal.md

2.5 KiB
Raw Blame History

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?
  • 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 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.

Extending cycle by a week

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:

  • Day 0: Create milestones for the next regression & feature release
  • Day 7: Regression release (optional)
  • Day 21: Beta release
  • Day 28: Beta 2 release
  • Day 31: Feature freeze and optional final beta
  • Day 35: Feature release

The downside is a slightly lower release velocity, the upside may be more a more stable final release.