New release- branches with no changes have that commit double-tagged about sig-release

[calebamiles]

I'm worried about having a change which exists on the release-1.10 branch but not on master

[david-mcmahon]

/assign @calebamiles @david-mcmahon

[calebamiles]

/assign @jdumars

[calebamiles]

/sig release

[jdumars]

thank you for quickly figuring this out!

[calebamiles]

@david-mcmahon, do we really want to make a dummy change to the release-1.10 branch since our ultimate goal is to be able to fast forward master into the release-1.10 branch or do we just want to fast forward master onto the branch today and cut the build?

[david-mcmahon]

Do I want to make a dummy change? No. Do we need to? Possibly. If we wait til the first branch fast forward, then the branch will continue to 'git describe' as v1.11.0-alpha.0 until then. That may have unforeseen ramifications. Also, when we finally do fast-forward, we'll want to put the tag at branch-point + 1, which is odd and fragile as well.

[ixdy]

another question: why are we even creating an alpha tag now? everything on master is still slated to end up in 1.10.

[david-mcmahon]

@calebamiles, there have always been changes that landed on the release branch at branch time. It would be ideal to replace the one we removed with another useful branch-specific, branch time change.

[calebamiles]

I suppose I still don't understand why we have branch specific changes made when cutting the branch. In my mind the steps I should do are

1. git checkout upstream/master
2. git checkout -b release-1.10
3. git push origin HEAD
4. ./anago release-1.10

[david-mcmahon]

@ixdy, taking yet another step back, why are we even branching before we really want a branch?

Having gone to that model has created quite a bit of juggling (here, here and here) in the tooling to guard against unintended consequences.

Having said that, yes, if we stick with this branch-and-fast-forward model, we could forego the alpha tag on master. This of course will require many tooling changes including to those guards above and it's somewhat of a paradigm shift in the way we think of branching. Expect fallout.

[david-mcmahon]

@calebamiles the history of changes to the branch at branch time included updating docs and pkg/version/base.go. Those were (at the time) reasonable changes, but are no longer necessary.
WRT to your steps above, all of it is handled via anago.

[calebamiles]

@david-mcmahon, I suppose that was my proposal for how to reenter into a place where anago handles things again since the existing release-1.10 branch isn't being consumed and could be sacrificed in the name of expediency.

[enisoc]

My impression is that changing the process to move branching until later is a bigger risk than David's "Proposal 1".

In case it wasn't clear above, it has already been the case historically that the release branch has commits that master doesn't. The term "fast-forward" for branchff has been a misnomer for a while; it's actually a merge commit. So the dummy commit in Proposal 1, while conceptually ugly, should be technically equivalent to the way things have been done for previous releases.

I don't think doing a branchff before tagging will help at this point. Since there are no commits on the release branch that aren't on master, it will end up (for once) doing an actual fast-forward with no merge commit, unless we modify the script to force one. That means we'll still end up tagging a commit that also exists on master, and master will once again git describe as being 1.10-beta instead of 1.11-alpha.

[david-mcmahon]

@enisoc thanks for highlighting and raising that important point. So now to figure out a good post-branch commit replacement that's at least somewhat useful.

[david-mcmahon]

Tag v1.10.0-beta.0 updated on release-1.10 branch. This should finally resolve the orphaned v1.10.0-beta.0 tag issue.