Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Versioned API descriptions breaks existing release flow #10825

Closed
zmerlynn opened this issue Jul 7, 2015 · 1 comment
Closed

Versioned API descriptions breaks existing release flow #10825

zmerlynn opened this issue Jul 7, 2015 · 1 comment
Labels
area/build-release priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.

Comments

@zmerlynn
Copy link
Member

zmerlynn commented Jul 7, 2015

#10690 doesn't work with our existing release flow. I thought it did, but, from #10812 (comment):

The process we use right now is to create the release branch locally, tag it, propose a PR (like this one), then push the branch. Most of those instructions are actually sitting right in mark-new-version.sh, and some are here: https://github.com/zmerlynn/kubernetes/blob/i1883/docs/devel/releasing.md#branching-tagging-and-merging.

The problem, and I didn't really think about it long enough when it went in, is that the new sandwich commit you're creating, is always going to get backmerged back like this - git will always try to mutate head from the release version. We take that as good from the release version because we've been trying to keep the head version in sync with the patch version (long story), but not for these cases.

We do have a weird cost for merging back and forth between release N-1 and master (we try to keep the release tags merged back to master). Not sure how to crack this particular nut.

cc @eparis @thockin

closing out #10812.
@zmerlynn zmerlynn added priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. area/build-release labels Jul 7, 2015
@zmerlynn
Copy link
Member Author

zmerlynn commented Jul 7, 2015

Actually, I just realized my last suggestion in #10812 (comment) isn't the worst. The pull requests to master are essentially only there to get the tags backmerged, so we can construct a release branch like so:

Doc version -> Ver -> Ver'

and then a release branch backmerge branch like so:

Doc version -> Ver -> Ver' -> Doc version suppression

and it'll still work.

@zmerlynn zmerlynn mentioned this issue Jul 7, 2015
Merged
zmerlynn added a commit to zmerlynn/kubernetes that referenced this issue Jul 7, 2015
@zmerlynn
Change build/mark-new-version.sh to always create a backmerge branch
0185809 
that reverts the doc diff.

This changes mark-new-version to create a backmerge branch that will
additionally handle the revert of the doc diff that's now created for
every release.

Sidebar: I really wish I knew a good git visualizer for GitHub - this
thing is going to start creating some awesome Gordian knots of merges.
(Or more like little Omegas, since they basically just change
version/base.go.)

Fixes kubernetes#10825
@zmerlynn zmerlynn mentioned this issue Jul 7, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/build-release priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@zmerlynn