From 0f5829b0e3eb8fb405facec6094b29d0d53e3310 Mon Sep 17 00:00:00 2001 From: Ajay Kannan Date: Fri, 9 Oct 2015 09:46:43 -0700 Subject: [PATCH 1/4] Add RELEASING.md --- RELEASING.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 RELEASING.md diff --git a/RELEASING.md b/RELEASING.md new file mode 100644 index 000000000000..15c7d785a31b --- /dev/null +++ b/RELEASING.md @@ -0,0 +1,24 @@ +### Overview + +Most of the release process is handled by the `after_success.sh` script, triggered after Travis CI successfully completes a non-PR build. A new artifact will be released to Maven Central Repository via Travis CI when "-SNAPSHOT" is not included in the version (as listed in the base directory's `pom.xml`). The website and README files will also be updated automatically in this case. When "-SNAPSHOT" is included in the version, Travis only updates the artifact in the snapshot repository. + +### To push a release version + +1. Run `utilities/update_pom_version.sh` from the repository's base directory. +This script takes an optional argument denoting the new version. By default, if the current version is X.Y.Z-SNAPSHOT, the script will update the version in all the pom.xml files to X.Y.Z. If desired, another version can be supplied via command line argument instead. + +2. Create a PR to update the pom.xml version. +The PR should look something like [#225](https://github.com/GoogleCloudPlatform/gcloud-java/pull/225). After this PR is merged into GoogleCloudPlatform/gcloud-java, Travis CI will push a new website to GoogleCloudPlatform/gh-pages, push a new artifact to the Maven Central Repository, and update versions in the README files. + +3. Run `utilities/update_pom_version.sh` again (to include "-SNAPSHOT" in the project version). +As mentioned before, there is an optional version argument. By default, the script will update the version from "X.Y.Z" to "X.Y.Z+1-SNAPSHOT". Suppose a different version is desired, for example X+1.0.0-SNAPSHOT. Then the appropriate command to run would be `utilities/update_pom_version.sh X+1.0.0-SNAPSHOT`. + +4. Create and merge in another PR to reflect the updated project version. For an example of what this PR should look like, see [#227](https://github.com/GoogleCloudPlatform/gcloud-java/pull/227). + +### To push a snapshot version + +Pushing a snapshot is completely automated. If "-SNAPSHOT" is included in the version denoted by the base directory's pom.xml, then an updated artifact will be pushed to the snapshot repository when Travis CI successfully completes a non-PR build. + +### Improvements + +Tagging is not currently implemented, though it was discussed in #119. If the version updates continue to be manual, a one-line git tag command can be added to `after_success.sh` to correctly tag releases. However, if the release process becomes fully automated, tagging becomes a harder problem, as mentioned in that issue. From b574e90d2af67601dbf727d1e29f63ddcc2d8be6 Mon Sep 17 00:00:00 2001 From: Ajay Kannan Date: Fri, 9 Oct 2015 10:10:03 -0700 Subject: [PATCH 2/4] Add step for tag and github release --- RELEASING.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 15c7d785a31b..4dcf6013e416 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -10,10 +10,13 @@ This script takes an optional argument denoting the new version. By default, if 2. Create a PR to update the pom.xml version. The PR should look something like [#225](https://github.com/GoogleCloudPlatform/gcloud-java/pull/225). After this PR is merged into GoogleCloudPlatform/gcloud-java, Travis CI will push a new website to GoogleCloudPlatform/gh-pages, push a new artifact to the Maven Central Repository, and update versions in the README files. -3. Run `utilities/update_pom_version.sh` again (to include "-SNAPSHOT" in the project version). +3. Create a release on Github manually. +Go to the [releases page](https://github.com/GoogleCloudPlatform/gcloud-java/releases) and click "Draft a new release." + +4. Run `utilities/update_pom_version.sh` again (to include "-SNAPSHOT" in the project version). As mentioned before, there is an optional version argument. By default, the script will update the version from "X.Y.Z" to "X.Y.Z+1-SNAPSHOT". Suppose a different version is desired, for example X+1.0.0-SNAPSHOT. Then the appropriate command to run would be `utilities/update_pom_version.sh X+1.0.0-SNAPSHOT`. -4. Create and merge in another PR to reflect the updated project version. For an example of what this PR should look like, see [#227](https://github.com/GoogleCloudPlatform/gcloud-java/pull/227). +5. Create and merge in another PR to reflect the updated project version. For an example of what this PR should look like, see [#227](https://github.com/GoogleCloudPlatform/gcloud-java/pull/227). ### To push a snapshot version @@ -21,4 +24,4 @@ Pushing a snapshot is completely automated. If "-SNAPSHOT" is included in the v ### Improvements -Tagging is not currently implemented, though it was discussed in #119. If the version updates continue to be manual, a one-line git tag command can be added to `after_success.sh` to correctly tag releases. However, if the release process becomes fully automated, tagging becomes a harder problem, as mentioned in that issue. +Automatic tagging is not currently implemented, though it was discussed in #119. If the version updates continue to be manual, a one-line git tag command can be added to `after_success.sh` to correctly tag releases. However, automatically creating useful annotations for this tag will be difficult. Also, if the release process becomes fully automated, tagging becomes a harder problem, as mentioned in that issue. From 2f0bf9ace6020d10b7c47cf4d3b8781c7c77fd70 Mon Sep 17 00:00:00 2001 From: Ajay Kannan Date: Fri, 9 Oct 2015 13:56:15 -0700 Subject: [PATCH 3/4] Add conventions for releases --- RELEASING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index 4dcf6013e416..961947ae0cd4 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -11,7 +11,7 @@ This script takes an optional argument denoting the new version. By default, if The PR should look something like [#225](https://github.com/GoogleCloudPlatform/gcloud-java/pull/225). After this PR is merged into GoogleCloudPlatform/gcloud-java, Travis CI will push a new website to GoogleCloudPlatform/gh-pages, push a new artifact to the Maven Central Repository, and update versions in the README files. 3. Create a release on Github manually. -Go to the [releases page](https://github.com/GoogleCloudPlatform/gcloud-java/releases) and click "Draft a new release." +Go to the [releases page](https://github.com/GoogleCloudPlatform/gcloud-java/releases) and click "Draft a new release." Use `vX.Y.Z` as the "Tag Version" and `X.Y.Z` as the "Release Title", where `X.Y.Z` is the release version as listed in the `pom.xml` files. 4. Run `utilities/update_pom_version.sh` again (to include "-SNAPSHOT" in the project version). As mentioned before, there is an optional version argument. By default, the script will update the version from "X.Y.Z" to "X.Y.Z+1-SNAPSHOT". Suppose a different version is desired, for example X+1.0.0-SNAPSHOT. Then the appropriate command to run would be `utilities/update_pom_version.sh X+1.0.0-SNAPSHOT`. From c1d1fb72463009421db951e618b67dd1885c1053 Mon Sep 17 00:00:00 2001 From: Ajay Kannan Date: Fri, 9 Oct 2015 16:26:24 -0700 Subject: [PATCH 4/4] Fix link to PR --- RELEASING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index 961947ae0cd4..419f723fe328 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -24,4 +24,4 @@ Pushing a snapshot is completely automated. If "-SNAPSHOT" is included in the v ### Improvements -Automatic tagging is not currently implemented, though it was discussed in #119. If the version updates continue to be manual, a one-line git tag command can be added to `after_success.sh` to correctly tag releases. However, automatically creating useful annotations for this tag will be difficult. Also, if the release process becomes fully automated, tagging becomes a harder problem, as mentioned in that issue. +Automatic tagging is not currently implemented, though it was discussed in [#119](https://github.com/GoogleCloudPlatform/gcloud-java/pull/119). If the version updates continue to be manual, a one-line git tag command can be added to `after_success.sh` to correctly tag releases. However, automatically creating useful annotations for this tag will be difficult. Also, if the release process becomes fully automated, tagging becomes a harder problem, as mentioned in that issue.