-
Notifications
You must be signed in to change notification settings - Fork 118
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.
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
Please tag REv2 2.1.0 2.2.0 [...] #253
Comments
2.3 should also include commit e956416. |
All of the features that have been added since that are dependent on a given version number have been implemented: - REv2.1: Command.output_paths instead of output_{files,directories}. - REv2.2: Platform properties in the Action message. - REv2.3: Resolving argv[0] relative to the working directory. - REv2.3: Virtual execution duration. Newer versions of Bazel now also support output_paths, but they will only start to use it if the remote execution service announces the right version number. This means we'd better get this correct going forward. Details: bazelbuild/remote-apis#253
In our last meeting, I think somebody asked for a git tag creation instruction? > git clone https://github.com/bazelbuild/remote-apis.git
> cd remote-apis
> git tag v2.2.0 ddca4b2
> git tag v2.1.0 b5123b1
...
> git push --tags origin Then you should be able to use the UI in https://github.com/bazelbuild/remote-apis/releases to create a release for each tag. |
In preparation for the introduction of our blob splitting protocol as extension to the remote execution api, we need to update the used remote execution api to a more recent version than v2.0.0. Since no new tags are available right now, we update to the preliminary protocol version v2.3 according to the following discussion: bazelbuild/remote-apis#253
I have tagged v2.1.0-rc1, v2.2.0-rc1, and v2.3.0-rc1. Assuming those releases look good, I will promote them soon. Given that we fell off the bandwagon on creating proper releases for a bit, my inclination is to tag head as v2.4.0, then try to be better about releases in the future. That's likely somewhat wrong, though, because I suspect there's more than one change that would require a version rev between 2.3.0 and head--I just don't know how much value trying to create a trail of proper releases really adds. Will discuss at the RE API sync. |
I have published the official release of v2.1.0 and v2.2.0. I have also published v2.3.0-rc2, which includes e956416. I have not yet gone through the remaining commits to decide if a v2.4.0 (or other versions) is warranted. |
The latest version of REv2 that has been tagged is 2.0.0. Let's add tags for some of the historical releases we did, so that it's clear to implementors what versions they should be announcing. This is especially important, now that Bazel is going to conditionally set
output_paths
based on the version announced by the server.The text was updated successfully, but these errors were encountered: