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 android:versionCode 'AND' android:versionName in app (eg /assets/www/js/config.js)
 * 3) Release Manager makes sure that android:versionCode in AndroidManifest.xml has been incremented for this release. Increment android:versionName if this is not a beta/alpha release. (look in /AndroidManifest.xml)
 * 4) 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!)
 * 5) 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)
 * 6) Release manager runs unit tests in Chrome browser to verify quality (usually in assets/www/test.html)
 * 7) Release Manager builds a debug version of apk and installs on to phone. Release manager tests the app against a QA script+.
 * 8) http://developer.android.com/training/basics/firstapp/running-app.html
 * 9) Release Manager/tech lead tags branch point after verifying the build
 * 10) ex. 'git tag v1.2' https://github.com/wikimedia/WLMMobile/commits/v1.1
 * 11) remember to push tags to origin
 * 12) Sign APK (if you don't have the signing key ask Tomasz or Arthur)
 * 13) CLI: http://developer.android.com/tools/publishing/app-signing.html
 * 14) Eclipse: http://stackoverflow.com/questions/3417122/how-to-use-eclipse-to-create-released-signed-apk
 * 15) Ant: Edit ant.properties
 * 16) Rename apk from App-release.apk to App-vX.Y.Z.apk
 * 17) Create md5 hash of the apk   and place the md5 on the Mobile/Release history page. Update the release date. Shortcut: http://www.mediawiki.org/w/index.php?title=Mobile/Release_history&action=edit&section=2
 * 18) Upload apk to download.wikimedia.org (usually by e-mailing the apk to Tomasz)
 * 19) Update Mobile/Release history  to include the link to the apk.
 * 20) Hand APK over to Product for inclusion in the market
 * 21) Product adds the new version market listing
 * 22) Product adds what's new section distilled down from tech change set
 * 23) Product activates on delivery date
 * 24) Product updates http://www.mediawiki.org/wiki/Mobile/Release_history with new release, md5sum, download link
 * 1) Product updates http://www.mediawiki.org/wiki/Mobile/Release_history with new release, md5sum, 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.