From 761755335e58e797c9c8da55f49870761d2ffe39 Mon Sep 17 00:00:00 2001 From: David Chang Date: Fri, 21 Aug 2020 14:12:57 -0700 Subject: [PATCH] Update release notes (#218) * Update release notes * numbers --- RELEASING.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index de66fe9..882d9c3 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -7,17 +7,18 @@ Releasing 4. `git commit -am "Prepare for release X.Y.Z."` (where X.Y.Z is the new version) 5. `git tag -a X.Y.X -m "Version X.Y.Z"` (where X.Y.Z is the new version) * Run `git tag` to verify it. - 6. Update the top level `build.gradle` to the next SNAPSHOT version. - 7. `git commit -am "Prepare next development version."` - 8. `git push && git push --tags` - 9. Create a PR with these 2 commits. - * **IMPORTANT** Add this comment to your PR "This is a release PR, it must be merged as individual commits. Do not squash commits on merge" - * Longer explanation: we release automatically through Travis CI. When Travis builds on master a script is run to send either a new shapshot or a new release version to Maven. If you squash the commits in the PR, Travis will only see what's left at the end, which is your commit to change back to `SNAPSHOT` release. Thus, Travis will not end up sending a release version to Maven. If you land as multiple commits, Travis will build both and send a release build to Maven for the commit where you bumped the version to a new release version. + 6. `git push && git push --tags` + * This should be pushed to your fork. + 7. Create a PR with this commit and merge it. + 8. Update the top level `build.gradle` to the next SNAPSHOT version. + 9. `git commit -am "Prepare next development version."` + 10. Create a PR with this commit and merge it. + 11. Login to Sonatype to promote the artifacts https://central.sonatype.org/pages/releasing-the-deployment.html **Note:** We are currently not pinning the sample app to the last version because the API is still fluid while `Store` is in alpha. We will resume pinning the sample app to a released version when we move to beta (see #159). When we're ready to pin, restore the final step: -10. Update the sample module's `build.gradle` to point to the newly released version. (It may take ~2 hours for artifact to be available after release) +12. Update the sample module's `build.gradle` to point to the newly released version. (It may take ~2 hours for artifact to be available after release) \ No newline at end of file