mobile/android/android-components/docs/contribute/versioning.md

   1 ---
   2 layout: page
   3 title: Versioning and release process
   4 permalink: /contributing/versioning
   5 ---
   6
   7 The *Android components* project uses a similar [versioning and release process as Firefox](https://wiki.mozilla.org/Release_Management/Release_Process) (New major version releases at fixed intervals).
   8
   9 ## Major releases
  10
  11 * Major releases happen at fixed intervals (currently on Tuesday every week)
  12 * Every release increments the major version (e.g. 1.0.0 -> 2.0.0 -> 3.0.0)
  13 * Major releases are tagged on and shipped from the `main` branch.
  14
  15 ## Point releases
  16
  17 * Point releases happen on demand whenever an app project requires a new version but cannot update to the latest release version yet or whenever a new release version is not available yet.
  18 * Point releases are created from a release branch, created from a previously tagged release.
  19 * The minor or patch version is increased depending on whether the release introduces backported functionality or just fixes bugs (e.g. 1.0.0 -> 1.1.0 or 2.0.0 -> 2.0.1).
  20
  21 ## Rationale and alternatives
  22
  23 #### Release cycle and stability
  24
  25 The *Android components* project follows a rapid release cycle to get new functionality into the hands of consuming apps as soon as possible. For this reason the project does not have a long release stability phase (e.g. 1.0.0 -> 1.0.1 -> 1.0.2 -> 1.1.0 -> 1.1.1).
  26
  27 App teams are encouraged to update to the latest release frequently. The *Android Components* team tries to minimize the amount of breaking API changes. Frequent updates minimize the amount of API changes when updating *Android Components*.
  28
  29 #### Versioning
  30
  31 All *Android Components* are released together using a unified version number. This makes it easy for the *Android Components* team to guarantee that this set of components is guaranteed and tested to work together.
  32
  33 The downside of a shared version is the loss of [semantic versioning](https://semver.org/) semantics on a per component level. It is entirely possible that a component is released using  a new major version and there's not a single code change in this component in the new release. Instead the [changelog](https://mozac.org/changelog/) is the primary mechanism to communicate major and minor changes in a component.
  34
  35 At this time individually semantically versioned components would introduce a too large maintenance overhead for the *Android Components* team (Individual releases, release manager/owner for every component, guaranteeing compatibility across many versions).