3 title: Versioning and release process
4 permalink: /contributing/versioning
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).
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.
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).
21 ## Rationale and alternatives
23 #### Release cycle and stability
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).
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*.
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.
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.
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).