Client-go: [PROPOSAL] inverse use of branches: master = stable, develop = nightly snapshots

[sttts]

With https://github.com/kubernetes/client-go/issues/83 and https://github.com/kubernetes/client-go/issues/78 in mind, I propose the following solution:

• turn the client-go master branch into our latest stable release branch
• publish nightly updates from k8s.io/kubernetes to the develop branch.

Then implement the following rules in our munge bot:

• k8s.io/kubernetes:master changed => push to client-go:develop, nightly
• k8s.io/kubernetes minor release is tagged of latest major release => push to client-go:master

and equivalently for k8s.io/apimachinery.

Optionally

• k8s.io/kubernetes:release-1.5 is changed => push to client-go:release-1.5, nightly
• k8s.io/kubernetes:release-1.6 is changed => push to client-go:release-1.6, nightly
• ...

Reasoning

• client-go must be go-gettable because people use this and expect it from any thirdparty package in the go ecosystem
• people will not follow or even know our release logic. They start pulling master into their (production) projects and get frustrated that we have regressions (compare Twitter thread).
• golang/dep might solve all golang dependency problems. But, we are still months away that people use it. And we might have a much longer time that people use glide or godep in their projects. We cannot force them to switch because kubernetes requires that.

Downsides

• kubernetes and apimachinery will have different branching logic (kubernetes:master and apimachinery:master might be incompatible)

Questions

• Does go-get support Github's default branch setting? Or will it always just get master?

/cc @deads2k @lavalamp @caesarxuchao

[ericchiang]

Does go-get support Github's default branch setting? Or will it always just get master?

It does respect the default branch. E.g. https://github.com/ericchiang/go-get-default-branch

$ go get github.com/ericchiang/go-get-default-branch
$ go-get-default-branch 
branch: v1

[sttts]

@ericchiang cool. IMO we would reduce a lot of pain for downstream users by switching the default branch to the release branch then. What is still open: does this work with the k8s.io/client-go redirect.

@lavalamp @thockin wdyt about this kind of switch? I prefer it over some gopkg.in magic (https://github.com/kubernetes/k8s.io/pull/49) as it is much more transparent. wdyt?

[caesarxuchao]

We had tried the default branch trick, @mbohlool @lavalamp do you remember why we didn't apply that?

[sttts]

Any update on this side? @lavalamp @thockin

[thockin]

I hate the model of "head isn't where development happens", in general, but
I could see an argument for it for the client libs. At that point, though,
why not go back to development in repo client-go-dev and cut releases to
repo client-go. It seems less likely to accidentally take a PR against
the wrong branch.

On Tue, Feb 14, 2017 at 1:26 AM, Dr. Stefan Schimanski <
[email protected]> wrote:

Any update on this side? @lavalamp https://github.com/lavalamp @thockin
https://github.com/thockin

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/90#issuecomment-279653128,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVJwbYupMOnmeT5pQ4gEjwbQzdi3Tks5rcXMqgaJpZM4L2bbP
.

[sttts]

I see the develop branch and dev-repo as more or less the same thing. Am also fine with the repo.

The only issue I see: if we switch to an external client-go repo some day for actual devlopment (not only do snapshots nightly), the client-go-dev repo idea will break down.

[WilliamDenniss]

I'm not a go expert, but I thought generally speaking that if you "start pulling master into your (production) projects" on any project, you're gonna have a bad time.

[rubenv]

@WilliamDenniss Generally (as Go projects mostly don't use versioning) master should be considered the stable branch, as that's the one go get pulls.

Almost all of the Go ecosystem works this way, so this is a pretty big deal.

[ericchiang]

@rubenv This is an expectation that many in the Go community are trying to get away from. e.g. https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases

I think it's reasonable to encourage using a release as long as it's well documented. The reason people pull master is because people don't tags semantic releases, and the lack of well documented tooling. Maybe "don't go get master" should be stressed more, earlier in client-go's docs?

[mbohlool]

Sorry I just see this. Using another branch (or even better another repo) looks good to me. About changing default branch, it is basically a renaming of branch master. All PRs will be defaulted to the new branch, first page shows new branch, etc. I don't see much value in renaming master.

[rubenv]

@ericchiang While I massively respect Dave Cheney, I don't think he speaks for the community as a whole.

Doesn't matter either, as it stands client-go is the only library that's causing such difficulties. Promoting vendoring is fine, but effectively forcing it upon people when it isn't commonly required is a bit of a pain.

[thockin]

On Wed, Mar 15, 2017 at 10:54 AM, Eric Chiang [e-mail] wrote:
>

@rubenv This is an expectation that many in the Go community are trying to get away from. e.g. https://dave.cheney.net/2016/06/24/gophers-please-tag-your-releases

I think it's reasonable to encourage using a release as long as it's well documented. The reason people pull master is because people don't tags semantic releases, and the lack of well documented tooling. Maybe "don't go get master" should be stressed more, earlier in client-go's docs?

Until go get supports tags or versions, this is a non-starter, IMO

[ericchiang]

@thockin I'm encouraging we stress NOT using go get earlier in client-go's README. Sorry if that wasn't clear.

[thockin]

And I am saying (unhappily) that I don't think it matters what you put in
the README. :)

On Wed, Mar 15, 2017 at 11:54 AM, Eric Chiang [e-mail]
wrote:

@thockin https://github.com/thockin I'm encouraging we stress NOT using go
get earlier in client-go's README. Sorry if that wasn't clear.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/90#issuecomment-286844139,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVGdUVpts1vZwj7V9njauUd0vBuodks5rmDPugaJpZM4L2bbP
.

[mbohlool]

We can creating stable-no-PRs branch and change github default branch to it and continue development on master. People that send PRs will see where they send PR and change the PR target to master (we should obviously document this too). To our eyes, branching is the same as kubernetes (master is development branch). go-get will get a stable version. We change stable-no-PRs branch to point to the latest version on each release. Except naming, this is the same thing @sttts is suggesting in the first post.

[thockin]

Yeah, I know it will cause pain to US, but a small amount of pain for us is
better than go get not working.

On Wed, Mar 15, 2017 at 1:49 PM, Mehdy Bohlool [e-mail]
wrote:

We can creating stable-no-PRs branch and change github default branch to
it and continue development on master. People that send PRs will see
where they send PR and change the PR target to master (we should obviously
document this too). To our eyes, branching is the same as kubernetes
(master is development branch). go-get will get a stable version. We
change stable-no-PRs branch to point to the latest version on each
release. Except naming, this is the same thing @sttts
https://github.com/sttts is suggesting in the first post.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/90#issuecomment-286874369,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVE7W-MmciV6j7ykiVMjaE25dpjt0ks5rmE7CgaJpZM4L2bbP
.

[jpoehnelt]

As a new user of go, this was a frustrating headache that took far too long to overcome.

[caesarxuchao]

A series of PRs will land soon to automatically publish k8s.io/kubernetes/staging to respective repos synchronously (e.g., apimachinery, client-go, apiserver, kube-aggregator, sampe-apiserver). This guarantees that

• the head of the master branches of these k8s.io repos are compatible,
• go get will create a single copy of an k8s.io repo and the dependent k8s.io repos in GOPATH (e.g., client-go depends on apimachinery), preventing issues like https://github.com/kubernetes/client-go/issues/83#issuecomment-280437996,
• the code are tested in the main kubernetes repo, because they passed pre-submit tetss before checking into k8s.io/kubernetes/staging/.

Are these guarantees good enough for go get users? If so, we can defer making a decision in this issue until we get rid of staging and start develop in repos.

[caesarxuchao]

Whatever we decide here, I think we'll have to impose the same structure in all k8s.io repos we separated from the main repo (apiserver, apimachinery, client-go, kube-aggregator etc.).

I like @mbohlool's suggestion, but i'm concerned with one particular operational cost: _we'll need to cut releases of these repos at the same time to make sure the stable-no-PRs branches (i.e., the latest releases) of these repos are compatible._

We have this requirement because these repos dependend on each other so go get one of the them will download others from the stable-no-PRs branches as well. Letting these repo vendor the dependent code in vendor/ is not an option, because that will cause t https://github.com/kubernetes/client-go/issues/83#issuecomment-280437996.

[thockin]

Are we going to do development outside of the "main" repo (ie directly in
the client-go repo) or is that repo only for re-publishing from main repo?

On Thu, Mar 16, 2017 at 1:01 AM, Chao Xu [e-mail] wrote:

Whatever we decide here, I think we'll have to impose the same structure
in all k8s.io repos we separated from the main repo (apiserver,
apimachinery, client-go, kube-aggregator etc.).

I like @mbohlool https://github.com/mbohlool's suggestion
https://github.com/kubernetes/client-go/issues/90#issuecomment-286874369,
but i'm concerned with one particular operational cost: we'll need to
cut releases of these repos at the same time to make sure the stable-no-PRs
branches (i.e., the latest releases) of these repos are compatible.

We have this requirement because these repos dependend on each other so go
get one of the them will download others from the stable-no-PRs branches
as well. Letting these repo vendor the dependent code in vendor/ is not an
option, because that will cause thttps://github.com/
kubernetes/client-go/issues/83#issuecomment-280437996.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/90#issuecomment-286983983,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVGG0Cr2SVprV_xXW1Wzvc7rqTRw3ks5rmOxGgaJpZM4L2bbP
.

[sttts]

Are we going to do development outside of the "main" repo (ie directly in
the client-go repo) or is that repo only for re-publishing from main repo?

Certainly not in the near future, at least until we agree on necessary tooling for multi-repo development. For 1.6.x and certainly 1.7 we will just sync daily with @caesarxuchao's nearly ready publish scripts, i.e. all the mentioned staging repos will extracted from k8s.io/kube, godeps updated and then pushed all at once (as atomically as we can do it with github).

[thockin]

In this model, the default branch on the client-go repo will be taking a
snapshot of development work, rather than stable, right? So I still think
we should do something whereby the default branch is the latest _release_,
and dev snapshots go somewhere else

On Thu, Mar 16, 2017 at 11:12 AM, Dr. Stefan Schimanski <
[email protected]> wrote:

Are we going to do development outside of the "main" repo (ie directly in
the client-go repo) or is that repo only for re-publishing from main
repo?

Certainly not in the near future, at least until we agree on necessary
tooling for multi-repo development. For 1.6.x and certainly 1.7 we will
just sync daily with @caesarxuchao https://github.com/caesarxuchao's
nearly ready publish scripts, i.e. all the mentioned staging repos will
extracted from k8s.io/kube, godeps updated and then pushed all at once
(as atomically as we can do it with github).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/90#issuecomment-287145447,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVMW5hGiSJ8AfRVoF5FaWhFiR-B5Rks5rmXuigaJpZM4L2bbP
.

[timothysc]

So long as I have a tag for the version released I don't really care.

I think everyone will expect tagging to be consistent across repos for release versions.

[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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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
/remove-lifecycle stale

[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