20 Commits

Author SHA1 Message Date
Tim Hockin
cb8e27230e When releasing, update versions in title 2015-07-10 09:04:19 -07:00
Tim Hockin
10ce2d2e38 Only subst things that exist 2015-07-09 17:17:49 -07:00
Tim Hockin
d6756c1fbd On release, always subst new version 2015-07-09 16:33:23 -07:00
Tim Hockin
e099a7f0e0 Fix quoting issue on sed 2015-07-08 16:53:51 -07:00
Tim Hockin
3d97d82655 Make READMEs clearer wrt versions 2015-07-08 11:36:14 -07:00
Zach Loafman
0185809a35 Change build/mark-new-version.sh to always create a backmerge branch
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 #10825
2015-07-07 10:44:00 -07:00
Tim Hockin
6a69a8f64b Remove dependency on perl 2015-07-04 13:32:23 -07:00
Tim Hockin
f3d3656fe6 Test for uncommited changes in and out of index 2015-07-04 13:32:23 -07:00
Tim Hockin
e7189041ee Preprocess API files to version URLs upon release 2015-07-04 13:32:23 -07:00
Brendan Burns
497d6019f2 Only clone docs on initial releases. 2015-06-15 20:23:09 -07:00
Brendan Burns
e051497be9 Add some text about the docs being sync'd to HEAD
Add pointers to the release branch files.
Clone docs when creating a new release.
2015-06-04 21:53:15 -07:00
Eric Paris
6b3a6e6b98 Make copyright ownership statement generic
Instead of saying "Google Inc." (which is not always correct) say "The
Kubernetes Authors", which is generic.
2015-05-01 17:49:56 -04:00
Zach Loafman
e4b613b514 Infer the URL from the existing git setup. (I don't push via ssh)
Also document using the recursive/ours merge strategy, because
it's almost certainly what we want to do in this case.
2015-04-02 10:15:18 -07:00
Eric Paris
e9d2c49fd4 Instructions to back-merge release branches into master
This allows us to continue on branched like v0.14.1, v0.14.2, and tag on
that branch.  But it will merge those tags into master so git describe
picks up the changes.
2015-03-30 17:31:15 -04:00
Eric Paris
a5732697fd update instructions to make it clear to get review 2015-03-30 15:10:34 -04:00
Eric Paris
329f9a0e99 Do not allow minor release which is not a decendant of the release branch
This does some git magic to make sure you do not tag a branch with
v0.13.3 unless that branch is a decendant of the release-0.13 branch
upstream.

Don't allow v0.13.4 if v0.13.3 doesn't exit

Don't allow v0.13.3 if v0.13.3 already exits
2015-03-27 21:24:10 -04:00
Eric Paris
cbefaf5d65 output current_branch name instead of HEAD in help messages 2015-03-27 19:03:42 -04:00
Eric Paris
2b941f4954 anchor version regex
Also create a GIT_MINOR variable for a touch of readability....
2015-03-27 18:54:36 -04:00
Eric Paris
3919a38ad6 make mark-new-release.sh do branching and tell you exactly what to do next
We keep getting tags and branches wonky.  This will land

v0.14.0 as an ancestor of master
v0.14.1 will NOT be an ancestor of master

I can do the later, it only a touch of git gymnastics, not really hard, but
we only occasionably do that today. (0.13.1 is an ancestor of master,
but 0.13.2 is not)
2015-03-27 17:01:56 -05:00
Joe Beda
35313c605c Script to help mark new versions 2014-11-24 12:24:29 -08:00