Bumpversion v0.3.0 by vbatts · Pull Request #294 · opencontainers/runtime-spec

vbatts · 2016-01-05T21:55:11Z

done in such a way to have a taggable v0.2.0 and then bump to a v0.3.0-dev
This way it's still jive with semver 2.0 section 10

crosbymichael · 2016-01-05T22:00:30Z

Whats in the change log? ;)

wking · 2016-01-05T22:05:45Z

On Tue, Jan 05, 2016 at 01:55:13PM -0800, Vincent Batts wrote:

done in such a way to have a taggable v0.2.0 and then bump to a v0.3.0-dev
This way it's still jive with semver 2.0 section 10

SemVer 2.0 §10 is about build-metadata. The -dev tag you're adding is
a pre-release version (§9). I'd suggest we use PreRelease in the Go
structure to match SemVer, but don't feel particularly strongly about
it. Otherwise, looks good to me.

And I'd like a changelog too 1, but that should land before the tag,
while this bump-to-dev should land after the tag, so that doesn't need
to happen in this PR.

philips · 2016-01-06T09:35:27Z

lgtm

vbatts · 2016-01-06T15:30:33Z

@crosbymichael would you rather a ./NEWS or ./ChangeLog file or just a write up in the release tag?

wking · 2016-01-06T17:31:21Z

On Wed, Jan 06, 2016 at 07:30:35AM -0800, Vincent Batts wrote:

@crosbymichael would you rather a ./NEWS or ./ChangeLog file or
just a write up in the release tag?

In projects where I'm the only member, I usually use the release-tag
approach. But having a file in the repository that can be updated
incrementally as branches land in master will make future releases
easier.

Include a changelog of commit subjects Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>

vbatts · 2016-01-07T20:35:12Z

I've added a ChangeLog. It is automatable, but not concise.

crosbymichael · 2016-01-09T01:36:47Z

LGTM

mrunalp · 2016-01-12T23:58:46Z

LGTM

Bumpversion v0.3.0

wking · 2016-01-13T00:11:42Z

On Tue, Jan 12, 2016 at 03:58:50PM -0800, Mrunal Patel wrote:

Merged #294.

I think our release process still needs some polish ;).

$ git log --graph --topo-order --oneline --decorate origin/master

837f67d (origin/master, origin/HEAD) Merge pull request Bumpversion v0.3.0 #294 from vbatts/bumpversion_v0.3.0
|\
| * bd81312 (vbatts/bumpversion_v0.3.0, origin/pr/294) version: bump v0.3.0-dev
| * 467fd17 (tag: v0.2.0) version: introduce a string for dev indication
| 6aa53ed Merge pull request style: Collect established conventions in a discoverable location #287 from wking/policy
|\ \
| * | 408412b (origin/pr/287, policy) style: Collect established styles in a discoverable location
| | 6a6ba67 (wking/master, master) Merge pull request runtime-config-linux: Add info to clarify oom_score_adj (carrying #236) #292 from vbatts/tiesheng_oomscoreadj
|\ \ \
| |_|/
|/| |
| * | 011acdf (vbatts/tiesheng_oomscoreadj, origin/pr/292) runtime-config: defer description to linux docs
| * | 153f13c (origin/pr/236) runtime-config-linux: clarify oom_score_adj
| | dd17705 Merge pull request Fix typo in Filesystem Bundle #291 from Ephemera/patch-1
…

So #292 and #287 landed before #294, but aren't actually part of
v0.2.0.

Do we want to land docs about who will update the ChangeLog and when?
Should that come in with the PR (likely to cause trivial merge
conflicts), or be added by the maintainer landing the PR (more work
for the maintainer), or be added right before cutting a release
(unlikely to lead to a usable ChangeLog)?

vbatts · 2016-01-13T00:27:43Z

@wking wacky. I tagged the commit after it hit master. :-\

wking · 2016-01-13T00:36:48Z

On Tue, Jan 12, 2016 at 04:27:47PM -0800, Vincent Batts wrote:

@wking wacky. I tagged the commit after it hit master. :-\

git-tag(1) will tag your current commit unless you explicitly specify
in your invocation. So when the branch lands in master
doesn't matter, but what you told git-tag and where your HEAD was
does. Running something like that log command [1](I have it aliased
to ‘glog’ [2]) before publishing the tag will help ensure you've
tagged the commit you meant to tag ;).

vbatts · 2016-01-13T00:47:08Z

my command was git tag -s v0.2.0 467fd17d4f2a987fa00051ce44b69bf9620e2ee6

On Tue, Jan 12, 2016 at 7:36 PM W. Trevor King notifications@github.com
wrote:

On Tue, Jan 12, 2016 at 04:27:47PM -0800, Vincent Batts wrote:

@wking wacky. I tagged the commit after it hit master. :-\

git-tag(1) will tag your current commit unless you explicitly specify
in your invocation. So when the branch lands in master
doesn't matter, but what you told git-tag and where your HEAD was
does. Running something like that log command 1(I have it aliased
to ‘glog’ 2) before publishing the tag will help ensure you've
tagged the commit you meant to tag ;).

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

wking · 2016-01-13T00:59:04Z

On Tue, Jan 12, 2016 at 04:47:11PM -0800, Vincent Batts wrote:

my command was git tag -s v0.2.0 467fd17d4f2a987fa00051ce44b69bf9620e2ee6

Then you got what you wanted, but I would have preferred history like:

xxxxxxx (origin/master, origin/HEAD) Merge pull request #### from vbatts/post-0.2.0
|
| * xxxxxxx version: bump from v0.2.0 to v0.3.0-dev
|/
xxxxxxx (tag: v0.2.0) Merge pull request Bumpversion v0.3.0 #294 from vbatts/pre-0.2.0
|
| * 467fd17 version: introduce a string for dev indication
| 6aa53ed Merge pull request style: Collect established conventions in a discoverable location #287 from wking/policy
…

Where the v0.2.0 tag contained the ChangeLog (like it does, so good
there) and all master work before the release (it's missing #287 and
#292) but not the v0.3.0-dev bump (which it does not, so good there).

With both the pre-release (ChangeLog) and post-release (v0.3.0-dev)
changes in a single branch, it's hard to do both. You'd have to
rebase onto the tip master, bumping the ChangeLog, etc. just before
merging:

xxxxxxx (origin/master, origin/HEAD) Merge pull request Bumpversion v0.3.0 #294 from vbatts/bumpversion_v0.3.0
|
| * xxxxxxx version: bump from v0.2.0 to v0.3.0-dev
| * xxxxxxx (tag: v0.2.0) version: introduce a string for dev indication
|/
6aa53ed Merge pull request style: Collect established conventions in a discoverable location #287 from wking/policy
…

My pull request landed on 2015-01-08 in 6aa53ed [1], although it missed the 0.2.0 tag [2]. Scoping is still waiting on feedback about "OCI Scope Table" referenced in the adopted charter [3]. [1]: opencontainers/runtime-spec#287 (comment) [2]: opencontainers/runtime-spec#294 (comment) [3]: Message-ID: <20151208201013.GF2767@odin.tremily.us> Subject: Re: OCI News (scoping) Date: Tue, 8 Dec 2015 12:10:13 -0800

wking · 2016-01-27T05:17:00Z

On Tue, Jan 12, 2016 at 04:09:40PM -0800, W. Trevor King wrote:

Do we want to land docs about who will update the ChangeLog and
when? Should that come in with the PR (likely to cause trivial
merge conflicts), or be added by the maintainer landing the PR (more
work for the maintainer), or be added right before cutting a release
(unlikely to lead to a usable ChangeLog)?

As a potential mitigating factor for the trivial merge conflicts of
“ChangeLog entries come with their PR”, I just learned that Gnulib has
a git-merge-changelog driver [1,2,3]. For an example project that
uses this approach, see 4 with PRs like 5.

vbatts · 2016-01-27T18:14:27Z

interesting tooling. we could put a pin in this, but not require action on
it just yet.

On Wed, Jan 27, 2016 at 12:17 AM W. Trevor King notifications@github.com
wrote:

On Tue, Jan 12, 2016 at 04:09:40PM -0800, W. Trevor King wrote:

Do we want to land docs about who will update the ChangeLog and
when? Should that come in with the PR (likely to cause trivial
merge conflicts), or be added by the maintainer landing the PR (more
work for the maintainer), or be added right before cutting a release
(unlikely to lead to a usable ChangeLog)?

As a potential mitigating factor for the trivial merge conflicts of
“ChangeLog entries come with their PR”, I just learned that Gnulib has
a git-merge-changelog driver [1,2,3]. For an example project that
uses this approach, see 4 with PRs like 5.

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

wking · 2016-01-27T19:00:09Z

On Wed, Jan 27, 2016 at 10:14:29AM -0800, Vincent Batts wrote:

interesting tooling. we could put a pin in this, but not require
action on it just yet.

We're curring 0.3.0 soon. Without some sort of plan for updating the
ChangeLog, I think we'll default to “added right before cutting a
release”, which is a fair amount of work to put on the releaser.

vbatts · 2016-01-27T19:10:07Z

I just pushed a minimal image to the docker hub
'vbatts/git-merge-changelog' that I was going to look at playing with

On Wed, Jan 27, 2016, 14:00 W. Trevor King notifications@github.com wrote:

On Wed, Jan 27, 2016 at 10:14:29AM -0800, Vincent Batts wrote:

interesting tooling. we could put a pin in this, but not require
action on it just yet.

We're curring 0.3.0 soon. Without some sort of plan for updating the
ChangeLog, I think we'll default to “added right before cutting a
release”, which is a fair amount of work to put on the releaser.

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

vbatts · 2016-01-27T20:06:39Z

i'm not sure this is the tool we're looking for. Testing the following. This utility is a helper for merge conflicts around a ChangeLog format file. Not to generate changelogs from merges.

[merge "merge-changelog"]
        name = GNU-style ChangeLog merge driver
        driver = /usr/bin/docker run -it --rm -v $(pwd):$(pwd) -w $(pwd) -u $(id -u) vbatts/git-merge-changelog %O %A %B

wking · 2016-01-27T20:13:10Z

On Wed, Jan 27, 2016 at 12:06:41PM -0800, Vincent Batts wrote:

i'm not sure this is the tool we're looking for. Testing the
following. This utility is a helper for merge conflicts around a
ChangeLog format file. Not to generate changelogs from merges.

Right, it's for the “ChangeLog entries come with their PR” workflow
(if that's what we want). If you want to generate entries from
merges, that's the “added right before cutting a release” workflow and
you probably want:

$ git log --first-parent --format='* %s%n%n%b%n' v0.2.0..

and a bunch of hand-editing to separate out breaking changes from
backwards compatible changes, etc.

vbatts added 2 commits January 7, 2016 10:23

version: introduce a string for dev indication

467fd17

Include a changelog of commit subjects Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>

version: bump v0.3.0-dev

bd81312

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>

vbatts force-pushed the bumpversion_v0.3.0 branch from 3d0059e to bd81312 Compare January 7, 2016 15:24

mrunalp pushed a commit that referenced this pull request Jan 12, 2016

Merge pull request #294 from vbatts/bumpversion_v0.3.0

837f67d

Bumpversion v0.3.0

mrunalp merged commit 837f67d into opencontainers:master Jan 12, 2016

vbatts deleted the bumpversion_v0.3.0 branch January 13, 2016 00:01

wking mentioned this pull request Jan 13, 2016

Clarify cwd #307

Merged

Conversation

vbatts commented Jan 5, 2016

Uh oh!

crosbymichael commented Jan 5, 2016

Uh oh!

wking commented Jan 5, 2016

Uh oh!

philips commented Jan 6, 2016

Uh oh!

vbatts commented Jan 6, 2016

Uh oh!

wking commented Jan 6, 2016

Uh oh!

vbatts commented Jan 7, 2016

Uh oh!

crosbymichael commented Jan 9, 2016

Uh oh!

mrunalp commented Jan 12, 2016

Uh oh!

wking commented Jan 13, 2016

I think our release process still needs some polish ;).

Uh oh!

vbatts commented Jan 13, 2016

Uh oh!

wking commented Jan 13, 2016

Uh oh!

vbatts commented Jan 13, 2016

Uh oh!

wking commented Jan 13, 2016

Uh oh!

wking commented Jan 27, 2016

Uh oh!

vbatts commented Jan 27, 2016

Uh oh!

wking commented Jan 27, 2016

Uh oh!

vbatts commented Jan 27, 2016

Uh oh!

vbatts commented Jan 27, 2016

Uh oh!

wking commented Jan 27, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants