2014-08-27 16:08:04 +00:00
|
|
|
/*
|
2016-06-03 00:25:58 +00:00
|
|
|
Copyright 2014 The Kubernetes Authors.
|
2014-08-27 16:08:04 +00:00
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
package version
|
|
|
|
|
|
|
|
// Base version information.
|
|
|
|
//
|
|
|
|
// This is the fallback data used when version information from git is not
|
|
|
|
// provided via go ldflags. It provides an approximation of the Kubernetes
|
|
|
|
// version for ad-hoc builds (e.g. `go build`) that cannot get the version
|
|
|
|
// information from git.
|
|
|
|
//
|
Enacting versioning.md
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
2015-07-20 17:48:29 +00:00
|
|
|
// If you are looking at these fields in the git tree, they look
|
|
|
|
// strange. They are modified on the fly by the build process. The
|
|
|
|
// in-tree values are dummy values used for "git archive", which also
|
|
|
|
// works for GitHub tar downloads.
|
2014-08-27 16:08:04 +00:00
|
|
|
//
|
Enacting versioning.md
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
2015-07-20 17:48:29 +00:00
|
|
|
// When releasing a new Kubernetes version, this file is updated by
|
2016-12-14 00:03:06 +00:00
|
|
|
// build/mark_new_version.sh to reflect the new version, and then a
|
Enacting versioning.md
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
2015-07-20 17:48:29 +00:00
|
|
|
// git annotated tag (using format vX.Y where X == Major version and Y
|
|
|
|
// == Minor version) is created to point to the commit that updates
|
|
|
|
// pkg/version/base.go
|
2014-08-27 16:08:04 +00:00
|
|
|
var (
|
Enacting versioning.md
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
2015-07-20 17:48:29 +00:00
|
|
|
// TODO: Deprecate gitMajor and gitMinor, use only gitVersion
|
|
|
|
// instead. First step in deprecation, keep the fields but make
|
|
|
|
// them irrelevant. (Next we'll take it out, which may muck with
|
|
|
|
// scripts consuming the kubectl version output - but most of
|
|
|
|
// these should be looking at gitVersion already anyways.)
|
|
|
|
gitMajor string = "" // major version, always numeric
|
|
|
|
gitMinor string = "" // minor version, numeric possibly followed by "+"
|
|
|
|
|
2016-07-13 14:06:24 +00:00
|
|
|
// semantic version, derived by build scripts (see
|
2015-12-11 20:27:24 +00:00
|
|
|
// https://github.com/kubernetes/kubernetes/blob/master/docs/design/versioning.md
|
Enacting versioning.md
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
2015-07-20 17:48:29 +00:00
|
|
|
// for a detailed discussion of this field)
|
|
|
|
//
|
|
|
|
// TODO: This field is still called "gitVersion" for legacy
|
|
|
|
// reasons. For prerelease versions, the build metadata on the
|
|
|
|
// semantic version is a git hash, but the version itself is no
|
|
|
|
// longer the direct output of "git describe", but a slight
|
|
|
|
// translation to be semver compliant.
|
|
|
|
gitVersion string = "v0.0.0-master+$Format:%h$"
|
|
|
|
gitCommit string = "$Format:%H$" // sha1 from git, output of $(git rev-parse HEAD)
|
2014-08-27 16:08:04 +00:00
|
|
|
gitTreeState string = "not a git tree" // state of git tree, either "clean" or "dirty"
|
2016-01-21 02:33:34 +00:00
|
|
|
|
|
|
|
buildDate string = "1970-01-01T00:00:00Z" // build date in ISO8601 format, output of $(date -u +'%Y-%m-%dT%H:%M:%SZ')
|
2014-08-27 16:08:04 +00:00
|
|
|
)
|