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

Enacting versioning.md: Prerelease versions between 1.0 and 1.1 #11495

Closed
zmerlynn opened this issue Jul 18, 2015 · 17 comments
Closed

Enacting versioning.md: Prerelease versions between 1.0 and 1.1 #11495

zmerlynn opened this issue Jul 18, 2015 · 17 comments

Comments

@zmerlynn
Copy link
Member

versioning.md describes a fanstasy that eventually needs to be enacted. I'm going to describe a super fast way to implement something, and if someone wants to do something better, they can maybe implement the infrastructure.

Right now, we only push git tags on major/minor/patch releases. I'm going to propose the following changes that actually get us to that document:

  • First, s/1.1-alpha.1/1.1.0-alpha.1/ to be semver compliant (minor patch to the existing design).
  • alpha releases are simply tags of known good hashes on master that we'll provide builds for on GCS in a known directory. Similar to how we're handling CI builds (which are wild wild west), we can provide a gs://kubernetes-release/ci/latest-alpha.txt that is the alpha build. We will literally just promote a previous git hash, i.e. v1.1.0-alpha.0-6-g84c76d1 will become v1.1.0-alpha.1, and we will push the binaries for that build (but not bother for intervening CI builds - and master will broadcast alpha.1-<y> for some <y> a few commits after the stamping).
  • There are no patches on alpha builds. If an alpha build is particularly crappy, we may stamp a new one that week, but that's it.
  • We abandon the backmerge process for patch releases completely. This is necessary if we adopt versioning.md, because the net effect of that document is that master will be broadcasting a 1.1.x tag, not a 1.0.x tag.
  • Somewhere down the line, we'll figure out a better process for beta. Maybe.
@zmerlynn
Copy link
Member Author

cc @eparis @roberthbailey @brendandburns

@zmerlynn
Copy link
Member Author

cc @ghodss

@zmerlynn
Copy link
Member Author

BTW, of particular note to @eparis maybe: alpha builds of this nature would not have any version information in the tarball. They would just look like master if you pulled them from, say, a GitHub snapshot. Our normal release process does so much grinding because it's really "make the GitHub tree look like a release-like image".

@ghodss
Copy link
Contributor

ghodss commented Jul 18, 2015

First, s/1.1-alpha1/1.1.0-alpha1.0/ to be semver compliant (minor patch to the existing design).

So, 1.1- to 1.1.0- makes sense. But the alpha1 should stay alpha1, not alpha1.0, because you would never release an alpha1.1, you would just increment alpha1 to alpha2 (the same way you would with beta). You seem to have it written that way (correctly) in your example too:

We will literally just promote a previous git hash, i.e. v1.1.0-alpha.0-6-g84c76d1 will become v1.1.0-alpha.1, and we will push the binaries for that build (but not bother for intervening CI builds - and master will broadcast alpha.1- for some a few commits after the stamping).

Re:

We abandon the backmerge process for patch releases completely. This is necessary if we adopt versioning.md, because the net effect of that document is that master will be broadcasting a 1.1.x tag, not a 1.0.x tag.

Can you elaborate a little more on what you mean when you refer to "the backmerge process for patch releases"?

@ghodss
Copy link
Contributor

ghodss commented Jul 18, 2015

Super glad we're proceeding with this BTW, it has not been making sense to me why a version like 0.21.0 is a "prerelease" but 0.21.3 and 0.21.4 are both "finals".

@zmerlynn
Copy link
Member Author

So, 1.1- to 1.1.0- makes sense. But the alpha1 should stay alpha1, not alpha1.0, because you would never release an alpha1.1, you would just increment alpha1 to alpha2 (the same way you would with beta).

Yeah, agreed.

Can you elaborate a little more on what you mean when you refer to "the backmerge process for patch releases"?

Today .. well, prior to today, and for a few months, we were doing some funny Git Jujitsu to get the tag on master to actually look vaguely correct. I'm proposing abandoning that, because it's crazy and unnecessary with this process. You can see an example of it in, say, #11097. If you look at that pull, it's a super weird commit, but it gets the tag v0.21.2 into master so that git describe on master happens to work.

(And it bumps the version files, but that's only important for the tarballs.)

@ghodss
Copy link
Contributor

ghodss commented Jul 18, 2015

Sounds good. Thanks again for driving this!

@zmerlynn
Copy link
Member Author

One fidgety bit is that continuous integration versions like v1.1.0-alpha.0-6-g84c76d1 are actually not semver compliant. Or, rather, they are, but if I'm reading the page correctly 0-6-g84c76d1 is interpreted as one giant precedence block. If we just translate continuous integration versions to e.g. v1.1.0-alpha.0.6+g84c76d1, they are.

This was referenced Jul 21, 2015
Closed
Merged
@bgrant0607
Copy link
Member

semver says the form should be 1.X.Y-alpha

I find it confusing that 1.1.10-alpha < 1.1.0.

@zmerlynn
Copy link
Member Author

Hrm? 1.1.10-alpha should be greater than 1.1.0 but less than 1.1.10. (Major, minor, patch.)

@thockin
Copy link
Member

thockin commented Jul 22, 2015

I would hope it works like:

1.1.0-alpha1, 1.1.0-alpha2 = master branch while we're doing development (I
would prefer "dev" to "alpha")
1.1.0-beta1, 1.1.0-beta2 = master branch while we're stabilizing
1.1.0-rc1 = release branch
1.1.0,1.1.1,1.1.2 = release branch
1.2.0-alpha1 = master branch while we're doing development

On Wed, Jul 22, 2015 at 1:54 PM, Zach Loafman notifications@github.com
wrote:

Hrm? 1.1.10-alpha should be greater than 1.1.0 but less than 1.1.10.
(Major, minor, patch.)

—
Reply to this email directly or view it on GitHub
#11495 (comment)
.

@ghodss
Copy link
Contributor

ghodss commented Jul 22, 2015

Precisely right, though @bgrant0607 wants to kill -rcX in #11708.

@zmerlynn
Copy link
Member Author

@thockin: Yes, except they're spelled 1.1.0-alpha.1, etc. (You can actually have numeric dot matter past your alpha matter, and it has precedence meaning in semver-speak.)

@zmerlynn
Copy link
Member Author

I'm being super nitpicky, but we have existing parsers that vaguely care, and I wouldn't actually mind ditching some of them for semver parsers, too. (I even have a Google internal one that attempts to care about the prerelease matter for figuring out if it's a release version, because sigh.)

@bgrant0607
Copy link
Member

Read semver again. My interpretation is that we need 1.1.0-alpha.X for minor versions X preceding 1.1.0

@zmerlynn
Copy link
Member Author

I think we're agreeing violently with each other.

@bgrant0607
Copy link
Member

Indeed. Updated #11708.

zmerlynn added a commit that referenced this issue Jul 28, 2015
@zmerlynn
Enacting versioning.md
4363f14 
This PR changes how we version going forward in the following ways:

* mark-new-version.sh is changed to a new policy of just splitting
branches, rather than the old backmerge policy, as discussed in
vX.Y.0, and a tag for vX.(Y+1).0-alpha.0 back to master.

* I eliminated PRs back to master by making the version/base.go
gitVersion and gitCommit just be `export-subst`. I testing that this
works with GitHub's source export tarballs. There's no reason to
bother with forcing the version into `base.go` (especially twice). The
tarball versions outside a git tree aren't perfect (master looks like
"v0.0.0+hash", and the release branches look more accurate), but our
build contract has never allowed that version is perfect in this
situation, so I think we can relax this.

* That master tag gets picked up by "git describe" on master, so e.g.
master would have immediately become v1.1.0-alpha.0

* In order to be more semVer compatible, the gitVersion field for the
master branch now looks something like 1.1.0-alpha.0.6+84c76d1142ea4d.
This is a tiny translation of the "git describe". I did this because
there are a ton of consumers out there of the "gitVersion" field
expecting it to be the full version, but it would be nice if this
field were actually semver compliant. (1.1.0-alpha.0-6-84c76d1142ea4d
is, but it's not *usefully* so.)

Fixes #11495
@zmerlynn zmerlynn mentioned this issue Jul 28, 2015
Merged
zmerlynn added a commit to zmerlynn/kubernetes that referenced this issue Jul 31, 2015
@zmerlynn
Enacting versioning.md
fd23207 
This PR changes how we version going forward in the following ways:

* mark-new-version.sh is changed to a new policy of just splitting
branches, rather than the old backmerge policy, as discussed in
vX.Y.0, and a tag for vX.(Y+1).0-alpha.0 back to master.

* I eliminated PRs back to master by making the version/base.go
gitVersion and gitCommit just be `export-subst`. I testing that this
works with GitHub's source export tarballs. There's no reason to
bother with forcing the version into `base.go` (especially twice). The
tarball versions outside a git tree aren't perfect (master looks like
"v0.0.0+hash", and the release branches look more accurate), but our
build contract has never allowed that version is perfect in this
situation, so I think we can relax this.

* That master tag gets picked up by "git describe" on master, so e.g.
master would have immediately become v1.1.0-alpha.0

* In order to be more semVer compatible, the gitVersion field for the
master branch now looks something like 1.1.0-alpha.0.6+84c76d1142ea4d.
This is a tiny translation of the "git describe". I did this because
there are a ton of consumers out there of the "gitVersion" field
expecting it to be the full version, but it would be nice if this
field were actually semver compliant. (1.1.0-alpha.0-6-84c76d1142ea4d
is, but it's not *usefully* so.)

Fixes kubernetes#11495
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@zmerlynn @ghodss @thockin @bgrant0607