Update release notes (#218)

* Update release notes

* numbers
This commit is contained in:
David Chang 2020-08-21 14:12:57 -07:00 committed by GitHub
parent 1a4b0b0966
commit 761755335e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -7,17 +7,18 @@ Releasing
4. `git commit -am "Prepare for release X.Y.Z."` (where X.Y.Z is the new version) 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) 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. * Run `git tag` to verify it.
6. Update the top level `build.gradle` to the next SNAPSHOT version. 6. `git push && git push --tags`
7. `git commit -am "Prepare next development version."` * This should be pushed to your fork.
8. `git push && git push --tags` 7. Create a PR with this commit and merge it.
9. Create a PR with these 2 commits. 8. Update the top level `build.gradle` to the next SNAPSHOT version.
* **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" 9. `git commit -am "Prepare next development version."`
* 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. 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). **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: 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)