We re-generate gen-go files and deploy jars to Maven Central under the following systems:
Other systems may also work, but we haven't verified them.
To generate the Go files from protos, you'll need to install protoc, protoc-gen-go and grpc-gateway plugins first. Follow the instructions here, here and here.
Then run the following commands to re-generate the gen-go files:
$ cd $(go env GOPATH)/src/github.com/census-instrumentation/opencensus-proto $ git checkout -b update-gen-go $ rm -rf gen-go $ cd src $ ./mkgogen.sh $ git add -A $ git commit -m "Update gen-go files."
Go through PR review and merge the changes to GitHub.
To generate the Ruby files from protos, you'll need to install grpc-tools gem.
gem install grpc-tools
Then run the following commands to re-generate the gen-ruby files:
$ git@github.com:census-instrumentation/opencensus-proto.git $ cd opencensus-proto $ git checkout -b update-gen-ruby $ rm -rf gen-ruby $ cd src $ ./mkrubygen.sh $ git add -A $ git commit -m "Update gen-ruby files."
To generate the Python files from protos, you'll need to install grpc-tools from PIP.
python -m pip install grpcio-tools
Then run the following commands to re-generate the gen-python files:
$ git checkout -b update-gen-python # Assume you're under opencensus-proto/ $ cd src $ ./mkpygen.sh $ git add -A $ git commit -m "Update gen-python files."
Our release branches follow the naming convention of v<major>.<minor>.x
, while the tags include the patch version v<major>.<minor>.<patch>
. For example, the same branch v0.4.x
would be used to create all v0.4
tags (e.g. v0.4.0
, v0.4.1
).
In this section upstream repository refers to the main opencensus-proto github repository.
Before any push to the upstream repository you need to create a personal access token.
Create the release branch and push it to GitHub:
$ MAJOR=0 MINOR=4 PATCH=0 # Set appropriately for new release $ JAVA_VERSION_FILES=(build.gradle) $ PYTHON_VERSION_FILES=(gen-python/version.py) $ git checkout -b v$MAJOR.$MINOR.x master $ git push upstream v$MAJOR.$MINOR.x
Enable branch protection for the new branch, if you have admin access. Otherwise, let someone with admin access know that there is a new release branch.
Open the branch protection settings for the new branch, by following Github's instructions.
Copy the settings from a previous branch, i.e., check
Protect this branch
Require pull request reviews before merging
Require status checks to pass before merging
Include administrators
Enable the following required status checks:
cla/google
continuous-integration/travis-ci
Uncheck everything else.
Click “Save changes”.
For master
branch:
0.5.0-SNAPSHOT
).$ git checkout -b bump-version master # Change version to next minor (and keep -SNAPSHOT and .dev0) $ sed -i 's/[0-9]\+\.[0-9]\+\.[0-9]\+\(.*CURRENT_OPENCENSUS_PROTO_VERSION\)/'$MAJOR.$((MINOR+1)).0'\1/' \ "${JAVA_VERSION_FILES[@]}" $ sed -i 's/[0-9]\+\.[0-9]\+\(.*CURRENT_OPENCENSUS_PROTO_VERSION\)/'$MAJOR.$((MINOR+1))'\1/' \ "${PYTHON_VERSION_FILES[@]}" $ ./gradlew build $ git commit -a -m "Start $MAJOR.$((MINOR+1)).0 development cycle"
$ git checkout master $ git merge --ff-only bump-version $ git push upstream master
For vMajor.Minor.x
branch:
0.4.0
). Commit the result and make a tag:$ git checkout -b release v$MAJOR.$MINOR.x # Change version to remove -SNAPSHOT and .dev0 $ sed -i 's/-SNAPSHOT\(.*CURRENT_OPENCENSUS_PROTO_VERSION\)/\1/' "${JAVA_VERSION_FILES[@]}" $ sed -i 's/dev0\(.*CURRENT_OPENCENSUS_PROTO_VERSION\)/'0'\1/' "${PYTHON_VERSION_FILES[@]}" $ ./gradlew build $ git commit -a -m "Bump version to $MAJOR.$MINOR.$PATCH" $ git tag -a v$MAJOR.$MINOR.$PATCH -m "Version $MAJOR.$MINOR.$PATCH"
0.4.1-SNAPSHOT
). Commit the result:# Change version to next patch and add -SNAPSHOT and .dev1 $ sed -i 's/[0-9]\+\.[0-9]\+\.[0-9]\+\(.*CURRENT_OPENCENSUS_PROTO_VERSION\)/'$MAJOR.$MINOR.$((PATCH+1))-SNAPSHOT'\1/' \ "${JAVA_VERSION_FILES[@]}" $ sed -i 's/[0-9]\+\.[0-9]\+\.[0-9]\+\(.*CURRENT_OPENCENSUS_PROTO_VERSION\)/'$MAJOR.$MINOR.dev$((PATCH+1))'\1/' \ "${PYTHON_VERSION_FILES[@]}" $ ./gradlew build $ git commit -a -m "Bump version to $MAJOR.$MINOR.$((PATCH+1))-SNAPSHOT"
$ git checkout v$MAJOR.$MINOR.x $ git merge --ff-only release $ git push upstream v$MAJOR.$MINOR.$PATCH $ git push upstream v$MAJOR.$MINOR.x
Deployment to Maven Central (or the snapshot repo) is for all of the artifacts from the project.
If you haven't done already, please follow the instructions here to set up the OSSRH (OSS Repository Hosting) account and signing keys. This is required for releasing to Maven Central.
Before building/deploying, be sure to switch to the appropriate tag. The tag must reference a commit that has been pushed to the main repository, i.e., has gone through code review. For the current release use:
$ git checkout -b v$MAJOR.$MINOR.$PATCH tags/v$MAJOR.$MINOR.$PATCH
The following command will build the whole project and upload it to Maven Central. Parallel building is not safe during uploadArchives.
$ ./gradlew clean build && ./gradlew -Dorg.gradle.parallel=false uploadArchives
If the version has the -SNAPSHOT
suffix, the artifacts will automatically go to the snapshot repository. Otherwise it's a release deployment and the artifacts will go to a staging repository.
When deploying a Release, the deployment will create a new staging repository. You'll need to look up the ID in the OSSRH UI (usually in the form of opencensus-*
).
Once all of the artifacts have been pushed to the staging repository, the repository must first be closed
, which will trigger several sanity checks on the repository. If this completes successfully, the repository can then be released
, which will begin the process of pushing the new artifacts to Maven Central (the staging repository will be destroyed in the process). You can see the complete process for releasing to Maven Central on the OSSRH site.
We follow the same package distribution process outlined at Python Packaging User Guide.
If you haven't already, install the latest versions of setuptools, wheel and twine:
$ python3 -m pip install --user --upgrade setuptools wheel twine
Before building/deploying, be sure to switch to the appropriate tag. The tag must reference a commit that has been pushed to the main repository, i.e., has gone through code review. For the current release use:
$ git checkout -b v$MAJOR.$MINOR.$PATCH tags/v$MAJOR.$MINOR.$PATCH
$ cd gen-python $ python3 setup.py sdist bdist_wheel $ python3 -m twine upload dist/*
Once deployment is done, go to Github release page, press Draft a new release
to write release notes about the new release.
You can use git log upstream/v$MAJOR.$((MINOR-1)).x..upstream/v$MAJOR.$MINOR.x --graph --first-parent
or the Github compare tool to view a summary of all commits since last release as a reference.
Please pick major or important user-visible changes only.