Wikimedia Apps/Android release policy
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. For up to date information on release policy, please go to https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Release_process |
This page details the release plan / cadence for updates to the Wikipedia Android app, with inspiration from WMF's release/deployment plans for server-side software.
Goals
[edit]- Releases should be, ideally, non-events. No big deal.
- Release early and release often, but not *too* often - since apps that update too often aren't looked upon favorably when they don't bring in new features with every update.
Schedule
[edit]- First day of every sprint, we release a new beta, cut out of master.
- Second day of every sprint, we release a new production version, which is the previous beta plus any bug fixes only. No new features.
- Get rid of the alpha, replace it with continuous integration builds from Jenkins (useful for really bleeding edge testers and for PM/Design)
This gives us:
- No confusion between Alpha and Production (which currently happens since they are the same listing on play store)
- A very stable production app, since all features would've had 2 weeks of usage by the (rather large) beta user group to iron bugs out
- Beta always leads stable in terms of features, so people will have an incentive to use the beta app
- PM/Design don't need to wait for the developers to cut a build to test things. Continuous integration builds will be produced after every commit has been merged, so instant signoff/design review can happen after every commit (One-off builds will still be necessary for things that aren't merged yet)
Versioning
[edit]- Production builds will be versioned as
2.0-rYYYY-MM-DD - Beta builds will be versioned as
2.0-beta-YYYY-MM-DD, as they are now - Continuous Integration builds will be versioned as
2.0-ci-YYYY-MM-DD, where the timestamp is that of the commit for which this build was produced
Including the date field in the version code makes it trivially easy to see when a version was last updated by end users. Each release will also be tagged with git tag, and a branch will be created and used for any bug fixes on top of one version. Details of how these should be handled in git will be worked out as we go along.
Exceptions
[edit]New builds can be rushed out out of cycle in emergency cases. This should be based on number of people affected and the severity of the bug. No emergency builds for new features. Done at the discretion of the Product Manager + Tech Lead.
Disadvantages
[edit]While this gives our users predictability and stability, it does mean a 1 sprint delay between us merging a feature and it being in the hands of everyone
TODO
[edit]Things that need to be done to make this plan possible:
- Document Git branching/tagging for beta + production releases.
- Make continuous integration produce APKs that people can download and install. Right now we don't really have much in the way of Java CI, except for Checkstyle (which we ignore atm).
- Built a tiny app/webpage that'll let people know if their current local install (from CI) is out of date, and if so, lets them easily update it.
- Scripts to make it possible to trivially produce beta/CI builds. We're mostly there already.