| # Versions and releases |
| |
| MDC's version numbers strictly follow [semantic versioning v2.0.0](https://semver.org/spec/v2.0.0.html): |
| `MAJOR.minor.patch`. In short, if the current version is `1.1.1`, then: |
| |
| * A major release has a version number of `2.0.0`. |
| * A minor release has a version number of `1.2.0`. |
| * A patch release has a version number of `1.1.2`. |
| |
| > These are *engineering* version numbers, intended for communicating to our engineering clients |
| > what type of follow-up work a upgrading to a release might entail. Since every breaking change |
| > bumps the major version number, we'll quickly run up to "large" major versions. That's ok. |
| |
| Major releases can contain breaking changes to clients, while minor and patch releases cannot. |
| |
| ## How do we determine which numbers need to change? |
| |
| We follow the guidelines defined by the [semver v2.0.0](https://semver.org/spec/v2.0.0.html#semantic-versioning-specification-semver) specification. |
| |
| Our public API includes the following: |
| |
| - APIs that are present in non-private headers. A private header is one that is contained within a sub-directory named `private/` within a `src/` directory. |
| |
| We define "backwards incompatible changes" to include the following: |
| |
| - Any change that will result in a build breakage from the previous release. |
| |
| ## What is the source of truth for MDC's version number? |
| |
| The [VERSION](https://github.com/material-components/material-components-ios/blob/develop/VERSION) |
| file contains the current version as a simple string (and nothing else). Our `scripts/release/bump` |
| script updates that number and copies it into all the locations that it needs to end up, e.g. |
| CocoaPods podspecs, etc. You can use the `scripts/print_version` script to print out the version |
| number of the library. |
| |
