Kubespray: Change in release management

[verwilst]

Since the whole Kubernetes scene is so much in flux, it's quite hard to keep up with everything and still maintain a somewhat stable cluster.
A couple of weeks after Kubespray releases a new version, I find myself needing a lot of stuff that's only available in master, forcing me back to master and its logical instability.
I therefor propose the following change to the current release management:

Example for new minor/major release:

• Tag v2.7.0 is created

• Branch 2.8 (or 2_8, ...) is created from master

• All incompatible/breaking/crazy stuff keep pouring into master.

• Branch 2.8 does not introduce new major changes ( like Calico change from 2.6 to 3.1/3.2 )

• Branch 2.8 only receives stability/bugfixes

• In the meantime v2.7.x get tagged from branch 2_7, only getting minor fixes or bugfix releases from included components ( Kubernetes v1.11.2 to v1.11.3, Ingress 0.17.0 to 0.17.1, .. )

NEW RELEASE:
It is decided that 2_8 is stable enough.

• Tag v2.8.0 is created
• Branch 2_9 is created from master

* rinse and repeat *

To keep maintenance burden low, only the latest stable branch and the one before for example could be supported ( When v2.9.0 is tagged, 2.7 is no longer maintained).

This all allows me for example, to switch to 2.8 and get the 'newer' stuff, while avoiding the wild changes happening in master.

What'ya say?

[arashkaffamanesh]

+1
Very nice.
We're developing this TK8 tool:
https://github.com/kubernauts/tk8
Which pulls a stable kubespray branch from a clone here:
https://github.com/kubernauts/kubespray/tree/version-0-4
It would be very helpful to use the suggested tag schema as proposed here.

[MuellerMH]

+1

[arush-sal]

+1

[anoopl]

+1

[ant31]

What could help in the short-term is to let open the release branches, so the community could do PR on them when necessary.
I'd personally not commit to maintaining more than 1 release, unless a contributor wants to cherry-pick and test releases. It's already complex to keep-up with the flow.

In your flow, releases are delayed from master by 1 cycle.

2.8 tagged from branch 2.8 that received only bugfixes/no-major changes since 2.7

• Day 0:
  
  
  
  • tag 2.7
  
  
  • branch 2.8 from master
  
  
• Day 60 (release 2.8):
  
  
  
  • branch-master: +400 commits since 2.7
  
  
  • Tag 2.8 from branch 2.8: +30 commits since 2.7
  
  
  • branch-2.9: +400commits since 2.7
  
  
• Day 120 (release 2.9):
  
  
  
  • tag 2.9 from branch 2.9: +430 commites since 2.7
  
  

If 2.8 is deployed, it will be equivalent of deploying master from ~60-90 days ago. To get what's on master we'll have to wait until the next release. This delay will raise maintenance and complexity in investigating and fixing issues .

One current problem is that there is no easy way to propose fixes on a release.
Keeping the release branch open would allow to receive PR on it, so we can release patched version more often

• release-branch&TAG 2.7 is created from master
• Branch 2.7 only receives ~stability/bugfixes~: only security fixes and major issues from on of the components. and get tagged 2.7.x

[fejta-bot]

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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.