New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brainstorming on faster releases #567

Open
bgrant0607 opened this Issue Apr 21, 2017 · 11 comments

Comments

Projects
None yet
@bgrant0607
Copy link
Member

bgrant0607 commented Apr 21, 2017

What if the biweekly Kubernetes releases were usable and stable?

What would be the benefits and challenges?

Some benefits are described here:

http://spf13.com/post/release-early-release-often-to-minimize-risk

Some issues / questions to consider:

  • Changes to development processes needed to ensure stability and that only functional features / APIs are exposed
    • Feature branches -- discuss in #566
    • Feature gating
  • Release process changes
    • LTS releases
    • Versioning scheme
    • Release notes
    • Feature/effort-tracking process
  • Documentation process and how to support documentation for multiple releases
  • Redefining supported version skew, and making it work
  • What testing would be necessary to ensure stability and backward compatibility
  • Further automation of upgrade tests (e.g., kubernetes/kubernetes#35078)
  • What upgrade procedures/tools would be tested?
  • Expression of which releases work for a given feature, test, Helm chart, etc.
  • Impact on conformance certification approach -- #432
  • Reducing disruption caused by cluster upgrades
  • Impact on marketing approach
    ...

This issue is intended to be a home for discussion on that topic.

cc @idvoretskyi @thockin @jagosan @pwittrock

@calebamiles

This comment has been minimized.

Copy link
Member

calebamiles commented Apr 25, 2017

cc: @philips

@pwittrock

This comment has been minimized.

Copy link
Member

pwittrock commented May 31, 2017

I tend to think of more frequent releases as 2 distinct problems, each of which are really challenging and will require a lot of effort.

Supporting the ability to perform a release at a moments notice

Target: developers
Benefit: stable and orderly release process

  • Decouple code from set of enabled features
    • Flag guard features until fully certified as ready to enable
  • Push on green
    • 100% confidence in test coverage ability to verify release
    • Dashboards with clear signal - ok / not ok
  • Continuous stability
    • Non-flaky tests
    • Immediately rollback PRs that break tests

Supporting publishing frequent releases

Target: End users
Benefit: Features available sooner, less dramatic changes per-release

  • Support for upgrade / downgrade process that fits users needs
    • Stepwise upgrades / downgrades no longer required (can skip minor versions)
    • Reduced service disruption in upgrade / downgrade process
    • Reduced ops time in upgrade / downgrade process
  • Clear client / server version compatibility
    • Support version skew for N releases
    • Clearly define which versions of client tools work with versions of server
@thockin

This comment has been minimized.

Copy link
Member

thockin commented Jun 11, 2017

@jagosan

This comment has been minimized.

Copy link
Contributor

jagosan commented Jun 11, 2017

@idvoretskyi

This comment has been minimized.

Copy link
Member

idvoretskyi commented Jun 11, 2017

@jagosan

That is, the user would choose to jump from 1.4 to 1.7, and the system
would incrementally move through interim releases in an automated process?

Hmm, can you describe this idea with more details?

@bgrant0607

This comment has been minimized.

Copy link
Member Author

bgrant0607 commented Jun 21, 2017

@G-Harmon

This comment has been minimized.

Copy link
Contributor

G-Harmon commented Jan 9, 2018

/cc me.

@fejta-bot

This comment has been minimized.

Copy link

fejta-bot commented Apr 9, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@idvoretskyi

This comment has been minimized.

Copy link
Member

idvoretskyi commented Apr 9, 2018

/remove-lifecycle stale

@fejta-bot

This comment has been minimized.

Copy link

fejta-bot commented Jul 8, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment