This is documentation for Android library & app maintainers at Particle for doing consistent releases. If this isn't you, you can safely ignore these docs!
If you were releasing version 2.4.2
, you'd do the following:
- Pull from origin to ensure you have the latest upstream changes
- Make sure CHANGELOG is current
- Update the
version
field incloudsdk/build.gradle
to'2.4.2'
- Build a release and publish it to JCenter. From the
cloudsdk
dir, do:../gradlew clean build install bintrayUpload
- Submit a PR to the Particle docs site updating the version code in
android.md
to2.4.2
- Update the SDK example app to pull the new SDK version from JCenter, do a clean build of the example app and then run it as a final smoke test.
- Commit and push the previous two changes
- Tag the release:
git tag cloudsdk-2.4.2
- Push the tag:
git push origin cloudsdk-2.4.2
- Create a GitHub release with a title of "Cloud SDK 2.4.2"
If you were releasing version 2.4.2
, you'd do the following:
- Pull from origin to ensure you have the latest upstream changes
- Make sure CHANGELOG is current
- Update the
version
field indevicesetup/build.gradle
to'2.4.2'
- Build a release and publish it to JCenter. From the
devicesetup
dir, do:../gradlew clean build install bintrayUpload
- Submit a PR to the Particle docs site updating the version code in
android.md
to2.4.2
- Update the device setup example app to pull the new setup lib version from JCenter, do a clean build of the example app and then run it as a final smoke test.
- Commit and push the above changes to the changelog & version fields
- Tag the release:
git tag devicesetup-2.4.2
- Push the tag:
git push origin devicesetup-2.4.2
- Create a GitHub release with a title of "Device Setup library 2.4.2"
If you were releasing version 2.4.2
, you'd do the following:
- Pull from origin to ensure you have the latest upstream changes
- Write user-facing release notes for the Play Store with a high-level description of the changes in this release
- Get product management signoff on the Play Store release notes
- Update CHANGELOG with a more detailed, technical description of these changes
- Update the
versionCode
field inapp/build.gradle
to102040201
[1], and update theversionName
field to2.4.2 (1)
(if this will only be released to alpha or beta channels) or just2.4.2
(if it will be pushed to production) - Uncomment the Google Services gradle plugins at the bottom of
app/build.gradle
, but don't commit this change. (This is kept commented out to make the app easily buildable by the community; if the plugin is enabled, the app won't build due to the lack of agoogle-services.json
file.) - Build a signed release APK
- Publish the APK to the appropriate channel (internal, alpha, or beta)
- Announce the release internally (i.e.: via Slack) and ask for testers in the appropriate channels
- Commit and push the above changes to the changelog & version fields
- Tag the release:
git tag app-2.4.2
- Push the tag:
git push origin app-2.4.2
- Create a GitHub release with a title of "Tinker app 2.4.2"
- Once the beta (etc) release has been tested appropriately, promote the build to production
- Announce production build availability on Slack and if appropriate, in the community forum: https://goo.gl/nEsGgK
[1] the versionCode scheme here is: EPOCH (single digit) MAJOR VERSION (2 digits) MINOR VERSION (2 digits) PATCH VERSION (2 digits) BUILD VERSION (2 digits)
So, the first released build of version 2.4.2 becomes: 1 02 04 02 01