Skip to content

Release Procedure

Jump to bottom
Joel Lonbeck edited this page Apr 7, 2015 · 5 revisions

Here are the steps that should be taken when releasing a new version of the app.

  • Update Project Source - For now we are packaging all of the available projects within the app (this may change in the future). In order to update the source you must use the latest version of the app to download all the sources. Then open up the developer tools within the app and export the source. This will provide you with an archive of the source which you may then copy/replace into the assets directory.

Important: when copying over the new project source you need to be sure to preserve the images in the obs project since these are not yet exported from the app. Later this process will be updated so you can blindly replace these files.

  • Update Target Languages - The target languages can be downloaded from the server tS API v.2 specification. You should update the appropriate file within the assets with this content.

  • Run Tests - A number of tests have been written to ensure critical components continue to function as improvements and fixes are made to the app. You should run these tests in order to ensure no regression has occurred.

  • Bump Build Number - The build number is the machine readable version of the app. This number should be incremented any time the apk is being built to be shared (not just for public releases).

  • Bump Version - Releases should cause the version numbers to be incremented according to the Semantic Versioning guidelines.

  • Tag Repository State - Once the above steps are completed you should commit all changes and create a tag marking the release. When tagging a development build you should create a tag using the following format for the title x.x.x-x where the x.x.x is the version and the trailing x is the build number. For public releases (releases published to the app store) you should exclude the trailing -x.

  • Push To Upstream - All new code changes and tags should be pushed to the upstream repository.

  • Draft Release - You should draft a new release using the recently pushed tag as the title. Be sure to include a list of new features as well as fixes. If you look at the last release you will find a link that shows all the commits made since that release. This is often a good source for organizing notes on the new release.

Clone this wiki locally