Wikimedia Apps/How to release an app

This is meant as a generic set of instructions. Your app may have subsequent steps that trump the ones documented below. Check with your tech lead to be sure.

= Versioning = Release versions should follow this scheme:. . -


 * A bug fix only release will increase the bit.
 * A release containing new features will increase the bit, and set bit to 0
 * A major overhaul of the code base will increase the release bit, and set and to 0.
 * The bit is set for non-stable releases, eg 'beta' or 'rc' (release candidate). This bit is only appended for non-stable releases. In the event of multiple beta or rc releases, append an incrementing digit. For instance, if current beta is 1.2.3-beta, but you need to make another beta release for the same version, it would become 1.2.3-beta1.

= Building for devices =

Android

 * 1) Generate release notes via
 * 2) Release manager increments any internal version number/name in app (eg /assets/www/js/config.js)
 * 3) Release manager makes a manual check to ensure any links to a test wiki have been moved to a production wiki.
 * 4) Release Manager makes sure that android:versionCode  AND android:versionName in AndroidManifest.xml has been incremented for this release. Increment android:versionName if this is not a beta/alpha release. (look in /AndroidManifest.xml)
 * 5) Release Manager commits the above. Commit message heading 'Release . . - ' commit body the content of RELEASE_NOTES (this reminds us the important of useful commit message headings!)
 * 6) Certain projects e.g. Wiki Loves Monument switch config for released version (e.g. to point to commons rather than test.wikipedia.org) - if this is so merge into the branch that lives on (for Wiki Loves Monuments this is commons-upload)
 * 7) Release manager runs unit tests in Chrome browser to verify quality (usually in assets/www/test.html)
 * 8) Release manager builds a debug version of apk and installs on to phone. Release manager tests the app against a QA script+.
 * 9) http://developer.android.com/training/basics/firstapp/running-app.html
 * 10) Release Manager tags branch point after verifying the build
 * 11) ex. 'git tag v1.2' https://github.com/wikimedia/WLMMobile/commits/v1.1
 * 12) remember to push tags to origin
 * 13) Sign APK (if you don't have the signing key ask Tomasz or Arthur)
 * 14) CLI: http://developer.android.com/tools/publishing/app-signing.html
 * 15) Eclipse: http://stackoverflow.com/questions/3417122/how-to-use-eclipse-to-create-released-signed-apk
 * 16) Ant: Get Tomasz to pass you the keystore file. Edit ant.properties and add   and  . Run   you will be prompted twice for a password - ask Tomasz what it is and enter this twice. It should create a file in the bin directory called App-release
 * 17) Rename apk from App-release.apk to App-vX.Y.Z.apk  - make sure to follow any past naming conventions
 * 18) Create md5 hash of the apk   and place the md5 on the Mobile/Release history page.
 * 19) Release manager uploads apk to download.wikimedia.org (usually by e-mailing the apk to Tomasz)
 * 20) Release manager updates Mobile/Release history to include the link to the apk and md5sum
 * 21) Release manager hands APK over to Product for inclusion in the market
 * 22) Product adds the new version market listing
 * 23) Product adds what's new section (release notes) distilled down from tech change set
 * 24) Product activates on delivery date
 * 25) Product updates http://www.mediawiki.org/wiki/Mobile/Release_history with new release, release notes, & download link
 * 1) Product updates http://www.mediawiki.org/wiki/Mobile/Release_history with new release, release notes, & download link

+ which may or may not exist

iOS

 * 1) Build according to our old docs
 * 2) Create a new version in itunes connect
 * 3) Archive the build
 * 4) Submit
 * 5) Publish after apple review is done

= App-specific notes =

WLM Mobile
The release version of the app currently exists in the remote branch 'commons-upload'. This is intended to preserve different config settings for development vs release. When a branch point is picked for the release, it should be merged into commons-upload, and the release tag applied to the commons-upload branch.

Version bumps need configuration changes in assets/www/js/config.js and AndroidManifest.xml.