Kubernetes release process

[Dmitriy Shulyak]

Hi all,

I want to ask several questions on mentioned topic, will be grateful for the feedback.

Releasing k8s are done based on semver specification [0] and there is no such process as change backport to a previous stable release,

it means that k8s will always maintain backward compatibility across MINOR version releases, is it correct?

Is there any criteria for a change that is accepted into PATCH release? Is there any connection between priority labels and maintenance release?

What about transitions from alpha to beta, and finally creating stable release? Based on what those decisions are made? 

Is there any additional testing performed before releasing?

0. http://semver.org/

[Ihor Dvoretskyi]

Dmitriy,

First of all, I'd like to let you know that the Kubernetes PM mailing list [0] has been established and it has to be the best place to discuss the similar questions.

Right now we are in a progress of working on the structuring the K8s releasing procedure, so your suggestions are welcome.

Thank you.

0. https://groups.google.com/forum/#!forum/kubernetes-pm 

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/264a3150-783d-4b03-9bdc-fa7fda4db5cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Paris]

On Tue, 2016-06-14 at 03:17 -0700, Dmitriy Shulyak wrote:
> Hi all,
> I want to ask several questions on mentioned topic, will be grateful
> for the feedback.
>
> Releasing k8s are done based on semver specification [0] and there is
> no such process as change backport to a previous stable release,
> it means that k8s will always maintain backward compatibility across
> MINOR version releases, is it correct?

Thus far backwards compat has been important, especially related to the
API objects. When we start to introduce V2 API objects I don't know if
we've decided if we will update the major version number. I doubt it,
since V1 objects should continue to work.

> Is there any criteria for a change that is accepted into PATCH
> release?

Thus far the criteria is 'someone who wrote/reviewed the PR against
master suggested it would be a good idea to have in the patch release
and the patch release branch manager agreed.'

> Is there any connection between priority labels and maintenance
> release?

No. We don't have a great definition of priorities. Its mostly how
important you feel your PR is. Some things, like many P0's are obvious.
The build is broken. Kubernetes is broken. Testing is broken. Anything
that would render development at a standstill is a P0. After that it's
really fluffy. But no, there is no statement that P0 would get
backported and a P1 would not, or anything like that.

> What about transitions from alpha to beta, and finally creating
> stable release? Based on what those decisions are made? 
> Is there any additional testing performed before releasing?

This has historically been done on a time based release often with the
time slipping to meet feature readiness if the feature was close but
was late. Around the 'feature complete' deadline we generally will
create a release branch and create a 'beta' build from the release
branch. (I don't know who makes alpha's or when). We then have a x3
week 'bug burn down' call to see how we are doing closing the P0/P1
issues and discuss how we think it best to steer and if we think we'll
get all those issues/bugs solved in time.

I do not think we have a proposed 1.4 schedule published yet.

I also don't know if the release branch gets a lot of EXTRA testing,
but it does get some. It also generally has fixes for all the bugs we
found in the normal testing...

[T.J. Goltermann]

We have a couple of links in our docs about these items, though they may be incomplete.  It's also clear our development docs are tough to discover or navigate :(

Versioning, Alpha Release Schedule, Patch Release Bug Bar - https://github.com/kubernetes/kubernetes/blob/master/docs/design/versioning.md

Issues/Priorities - https://github.com/kubernetes/kubernetes/blob/master/docs/devel/issues.md

1.4 and 1.5 Schedules -  https://github.com/kubernetes/community/wiki/Release-1.4

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/1465910920.4296.42.camel%40redhat.com.

For more options, visit https://groups.google.com/d/optout.

--

-T.J. Goltermann