Bump version for v0.1.0 #116

xiekeyang · 2017-02-16T03:17:57Z

There are merged 219 change-sets since the beginning and cleared the blockers for v0.1.0.

Signed-off-by: xiekeyang [email protected]

xiekeyang · 2017-02-16T03:22:28Z

Formerly version of image-tools followed up image-spec.
Here I present a new version.go, including the individual version of image-tools.

xiekeyang · 2017-02-17T02:06:26Z

Change version to v0.1.0

xiekeyang · 2017-02-20T08:53:10Z

@opencontainers/image-tools-maintainers We have got 7 LGTM votes for releasing v0.1.0. So PTAL thais PR.
In this PR I set up new file for individual image-tools version, without relationship to image-spec. In future that image-tools supports all stuff in image-spec, then I think we might need to claim a compatible series of image-spec version, via image-tools -v command.

cyphar · 2017-02-20T21:55:09Z

cmd/oci-image-validate/main.go

@@ -104,7 +104,7 @@ func newValidateCmd(stdout, stderr *log.Logger) *cobra.Command {
 func (v *validateCmd) Run(cmd *cobra.Command, args []string) {
 	if v.version {
 		v.stdout.Printf("commit: %s", gitCommit)
-		v.stdout.Printf("spec: %s", specs.Version)
+		v.stdout.Printf("spec: %s", version.Version)


This isn't correct. We should output separate lines for what spec versions we support, and the version of the actual tool.

Also, if we need to implement better version code we really should've gotten that merged before we had a vote. The vote is "this commit should be tagged", not "this PR should be merged in whatever state it is when someone clicks the merge button".

xiekeyang · 2017-02-21T01:41:42Z

This isn't correct. We should output separate lines for what spec versions we support, and the version of the actual tool.

It is separated line. But what mean actual tool version?

cyphar · 2017-02-21T01:45:16Z

The version of this tool is v0.1.0. It supports v1.0.0-rc4 of the spec. This PR is removing the latter information and saying that the tool supports 0.1.0 of the spec (which is incorrect). This is what the output should look like:

% <blah> --version
<blah> version 0.1.0
commit: <some hash>
spec: 1.0.0-rc4

Or something like that.

xiekeyang · 2017-02-21T01:45:24Z

Also, if we need to implement better version code we really should've gotten that merged before we had a vote. The vote is "this commit should be tagged", not "this PR should be merged in whatever state it is when someone clicks the merge button".

I did put up this PR, and then mail for voting. Or you have other proposal to correct this?

cyphar · 2017-02-21T01:55:50Z

@xiekeyang My concern is that you're adding new code for something that should just be a VERSION file bump. I mean, ultimately, I'd be willing to overlook it since we just didn't have the necessary code before (and I don't really want to go through another vote for no good reason). But I'm still a bit iffy about it.

xiekeyang · 2017-02-21T02:54:56Z

@cyphar

The version of this tool is v0.1.0. It supports v1.0.0-rc4 of the spec. This PR is removing the latter information and saying that the tool supports 0.1.0 of the spec (which is incorrect). This is what the output should look like:

% --version
version 0.1.0
commit:
spec: 1.0.0-rc4
Or something like that.

Thanks, I should have keep spec version, and add tools version individual. Now I update commit to 704b914. The version shows as:

$ ./xxx -v
commit: 98df00700ce69a83cde7a3707f3d5fab9fb86aa2
version: 0.1.0
spec: 1.0.0-rc4

PTAL, thanks.

xiekeyang · 2017-02-22T09:17:51Z

@cyphar Maybe I should not publish the vote result in this PR, and reback the comment, which bring out confusion. But if the bump is ready? I think after it is merged, then I should tag and release v0.1.0 package?
cc @opencontainers/image-tools-maintainers

cyphar · 2017-02-22T19:26:12Z

@xiekeyang For future reference, this is how the release process for OCI projects works:

You create a PR which has the list of issues and has two commits -- one which does the version bump and the other which switches it back to vX.X.X+dev. The commits should only be those changes. An example of this is Bump version image-spec#566.
You send an email to the ML to call for a vote on the commit hash which contains the version bump (5faaada in the case of image-spec 1.0.0-rc5).
People vote.
Once the vote passes, we merge the PR and then push a signed git tag (which tags the commit hash that was voted on) to make the release.

The reason why it's done this way is so that people can be certain what they're voting on. As it stands, the vote we had references a commit which doesn't exist anymore -- which is why the commit that is being voted on should not contain code.

Now, I'm of half a mind that we break out the versioning changes into a separate pull request, get that merged and then have another vote about the image-tools version with a properly set up PR. But that's just my opinion and I'd like to know what the other @opencontainers/image-tools-maintainers have to say.

wking · 2017-02-22T19:45:18Z

On Wed, Feb 22, 2017 at 11:26:13AM -0800, Aleksa Sarai wrote: 1. You create a PR which has the list of issues and has two commits -- one which does the version bump and the other which switches it back to `vX.X.X+dev`. The commits should _only_ be those changes. An example of this is opencontainers/image-spec#566.

You may want three commits, the two you mention here and an earlier commit updating your release notes. For example, see [1]. Having a ChangeLog entry makes it easier for maintainers to see what they're voting on, and makes it easy for other consumers to migate to the new release. There was some previous discussion about requiring ChangeLogs for OCI releases [2], but as far as I'm aware attempts to define release criteria have stalled out. The Core Infrastructure Initiative Best Practices Badge requires human-oriented release notes of some form [3], and gives projects a few ways to meet that criterion, a ChangeLog being one of them. I expect OCI projects that don't already supply release notes will begin adding them as they work on CII badging. Cheers, Trevor [1]: https://github.com/opencontainers/runtime-spec/pull/672/commits [2]: opencontainers/tob#15 (comment) [3]: https://github.com/linuxfoundation/cii-best-practices-badge/blob/5a0a7d0effe1fd92f5313142f918a0de3a8d241f/doc/criteria.md#change-control

…

-- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

xiekeyang · 2017-02-23T03:42:41Z

@cyphar Thank lots! I update it on 0cecf6b and 69a2401.
While I still have to contain some code in 0cecf6b, which is setting up image-tools version. If I separate it to individual commit, it is hard to write the right version. I think it should be OK for first version bump.

@wking As to add changelog, I didn't find it in similar cli tools repo as runtime-tools or docker/containerd. I think it might be not a well considered opinion yet, and I'd like to listen to opinions from @opencontainers/image-tools-maintainers.

cyphar · 2017-02-23T04:12:32Z

@xiekeyang umoci has one, as do an incredibly large number of other projects (all GNU projects for example). And we should include a changelog (as someone who does packaging for a distribution, changelogs are really helpful).

But a changelog for 500 commits where we don't have a previous version isn't really helpful IMO. Can we please get this versioned first.

cyphar · 2017-02-23T04:13:27Z

@wking We're already having enough troubles bumping a version. Please let's not pile more things on.

xiekeyang · 2017-02-23T05:08:07Z

@cyphar I agree the helpful changelog. But I honestly don't like to include it in this PR. Now I concern if this go forward on right direction.

wking · 2017-02-23T17:43:11Z

On Wed, Feb 22, 2017 at 08:12:33PM -0800, Aleksa Sarai wrote: But a changelog for 500 commits where we don't have a previous version isn't really helpful IMO.

I agree that you probably don't need a ChangeLog for the first release, since nobody is upgrading from a previous release. But after that, I think ChangeLogs are helpful. Even if there are 500 commits. Compiling a 500 commit ChangeLog entry would not be fun, but it is much more efficient to do it once as a community than it would be to have every consumer dig through those 500 commits on their own to see what changed. And if compiling a ChangeLog is so much trouble that it makes it hard to cut a release, then I think you need to cut more frequent releases and/or give up on CII badging. Certainly don't stop cutting releases, since that only makes it harder to figure out what changed.

xiekeyang · 2017-02-25T01:38:45Z

@vbatts @cyphar @stevvooe
If this bump PR is mostly ready, or still exist fault? Please point out directly if you find. Thank lots!

cyphar · 2017-02-25T03:26:42Z

LGTM, though I'm still quite frustrated that we had a vote which was not helpful (also exposing the version through an API is not necessary -- but we can fix that later). Let's just please get a version out so we can stop being blocked on this and start fixing everything else in image-tools that needs to get fixed.

cyphar · 2017-02-25T03:27:06Z

[ And for some reason PullApprove is still broken and doesn't recognise I'm a maintainer... ]

xiekeyang · 2017-02-25T04:09:17Z

@cyphar Thanks for you explain and excuse me that I want to comply with the process of bump and vote like image-spec, but I didn't put enough attention to the potential conflict between them.

About 4 steps you mentioned, they are what I think as same as in image-spec, and had tried to carry out. But for vote mail on v0.1.0 release, I think we have achieve the agreement to release tag including which commits, except bump commit. We note that vote ML (both image-spec and image-tools) announces the bump PR id, not the final commit id, (I think) that because it might need fix more. So, can we accept that after this bump PR is landed, then I release the v0.1.0 tag, without more vote?

I'm not sure if I fully catch the right processing. Of course if necessary, I'd have to send a new mail, but please let me clear the needed supplement in the mail firstly, to avoid introduce more problems. To be honest, now I'm still a little confused if fixing this bump PR invalidates the previous vote result.

cc @opencontainers/image-tools-maintainers

cyphar · 2017-02-26T05:52:01Z

@xiekeyang

We note that vote ML (both image-spec and image-tools) announces the bump PR id, not the final commit id, (I think) that because it might need fix more.

This is not correct. ML votes are on the commit to be tagged, not the pull request. This is why the subject of all vote emails is of the format [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC).

The reason it's done this way (as as opposed to voting on a PR) is because if someone rebases a PR and now the version will refer to a different codebase, it's difficult to see what the maintainers voted on. Voting on a commit ID means that everyone agrees what the history will look like and what will be tagged.

Now, this means that you cannot change the contents of the voted on commit (since the commit ID will change). This is also a good thing, because it also makes sure that everyone agrees what the code will look like once it's merged.

However, because you cannot change the commit, this means that you should not be making any code changes in a version bump. The reason for this should be obvious given the above comments. As an example, IMO this PR is currently invalidated because the commit that we voted on contained code changes that needed to be fixed.

So, can we accept that after this bump PR is landed, then I release the v0.1.0 tag, without more vote?

Sigh. While I feel like this is a bit too much bureaucracy-for-bureaucracy's-sake, we really shouldn't get into the habit of tagging commits that we didn't agree on.

Of course if necessary, I'd have to send a new mail, but please let me clear the needed supplement in the mail firstly, to avoid introduce more problems. To be honest, now I'm still a little confused if fixing this bump PR invalidates the previous vote result.

Unfortunately in my mind, it does invalidate the vote result (well unless you want to merge the old code which we voted on -- which was also incorrect). Sorry that I didn't check this PR properly before voting. Here's what we need to do in order for votes to go far more smoothly in future:

Take the version changes in this PR (the code changes to make the tooling display the version of the tools) and put them into a separate PR. Make the initial version 0.0.0-dev (which shouldn't need a vote because it's a dummy value).
Create a new PR after the above one is merged with two commits:

Bump to v0.1.0. this is the commit we vote on
Back to development (bump to v0.1.0+dev).

Post a mail on the ML to re-do the vote with the above commit.
Merge this once we get the vote done.

xiekeyang · 2017-02-27T11:21:48Z

As #122 landed, I update this patch. @cyphar @vbatts @wking please take an overlook. If this is the right direction, I would put up another vote by ML for v0.1.0 release. Thank lots!

cyphar · 2017-02-27T12:23:51Z

This looks fine. Send the email. 😸

Signed-off-by: xiekeyang <[email protected]>

cyphar · 2017-03-01T13:27:55Z

LGTM. Vote was +7 -0 #3.

coolljt0725 · 2017-03-01T13:50:25Z

LGTM

vbatts · 2017-03-01T13:58:17Z

LGTM

@cyphar

Bump to v0.1.0. Vote was +7 -0 #3. Closes #116 LGTMs: @cyphar @coolljt0725 @vbatts

cyphar · 2017-03-02T00:38:46Z

Tag pushed, release cut, binaries built and signed with my keys. https://github.com/opencontainers/image-tools/releases/tag/v0.1.0

xiekeyang changed the title ~~Bump version for v1.0.0-rc1~~ Bump version for v0.1.0 Feb 17, 2017

cyphar reviewed Feb 20, 2017

View reviewed changes

xiekeyang mentioned this pull request Feb 27, 2017

bump dummy version #122

Merged

xiekeyang added 2 commits February 28, 2017 10:05

version: release v0.1.0

c921af4

Signed-off-by: xiekeyang <[email protected]>

version: master back to -dev

220bc55

Signed-off-by: xiekeyang <[email protected]>

cyphar merged commit 220bc55 into opencontainers:master Mar 2, 2017

cyphar added a commit that referenced this pull request Mar 2, 2017

merge branch 'pr-116'

126c1bc

Bump to v0.1.0. Vote was +7 -0 #3. Closes #116 LGTMs: @cyphar @coolljt0725 @vbatts

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bump version for v0.1.0 #116

Bump version for v0.1.0 #116

xiekeyang commented Feb 16, 2017 •

edited

Loading

xiekeyang commented Feb 16, 2017

xiekeyang commented Feb 17, 2017

xiekeyang commented Feb 20, 2017

cyphar Feb 20, 2017

cyphar Feb 20, 2017

xiekeyang commented Feb 21, 2017

cyphar commented Feb 21, 2017

xiekeyang commented Feb 21, 2017

cyphar commented Feb 21, 2017

xiekeyang commented Feb 21, 2017

xiekeyang commented Feb 22, 2017

cyphar commented Feb 22, 2017

wking commented Feb 22, 2017 via email

xiekeyang commented Feb 23, 2017

cyphar commented Feb 23, 2017 •

edited

Loading

cyphar commented Feb 23, 2017

xiekeyang commented Feb 23, 2017

wking commented Feb 23, 2017 via email

xiekeyang commented Feb 25, 2017

cyphar commented Feb 25, 2017

cyphar commented Feb 25, 2017

xiekeyang commented Feb 25, 2017

cyphar commented Feb 26, 2017

xiekeyang commented Feb 27, 2017

cyphar commented Feb 27, 2017

cyphar commented Mar 1, 2017 •

edited by caniszczyk

Loading

coolljt0725 commented Mar 1, 2017 •

edited by caniszczyk

Loading

vbatts commented Mar 1, 2017 •

edited by caniszczyk

Loading

cyphar commented Mar 2, 2017

Bump version for v0.1.0 #116

Bump version for v0.1.0 #116

Conversation

xiekeyang commented Feb 16, 2017 • edited Loading

xiekeyang commented Feb 16, 2017

xiekeyang commented Feb 17, 2017

xiekeyang commented Feb 20, 2017

cyphar Feb 20, 2017

Choose a reason for hiding this comment

cyphar Feb 20, 2017

Choose a reason for hiding this comment

xiekeyang commented Feb 21, 2017

cyphar commented Feb 21, 2017

xiekeyang commented Feb 21, 2017

cyphar commented Feb 21, 2017

xiekeyang commented Feb 21, 2017

xiekeyang commented Feb 22, 2017

cyphar commented Feb 22, 2017

wking commented Feb 22, 2017 via email

xiekeyang commented Feb 23, 2017

cyphar commented Feb 23, 2017 • edited Loading

cyphar commented Feb 23, 2017

xiekeyang commented Feb 23, 2017

wking commented Feb 23, 2017 via email

xiekeyang commented Feb 25, 2017

cyphar commented Feb 25, 2017

cyphar commented Feb 25, 2017

xiekeyang commented Feb 25, 2017

cyphar commented Feb 26, 2017

xiekeyang commented Feb 27, 2017

cyphar commented Feb 27, 2017

cyphar commented Mar 1, 2017 • edited by caniszczyk Loading

coolljt0725 commented Mar 1, 2017 • edited by caniszczyk Loading

vbatts commented Mar 1, 2017 • edited by caniszczyk Loading

cyphar commented Mar 2, 2017

xiekeyang commented Feb 16, 2017 •

edited

Loading

cyphar commented Feb 23, 2017 •

edited

Loading

cyphar commented Mar 1, 2017 •

edited by caniszczyk

Loading

coolljt0725 commented Mar 1, 2017 •

edited by caniszczyk

Loading

vbatts commented Mar 1, 2017 •

edited by caniszczyk

Loading