We propose to regularly update the minimum supported major OS version as follows:

• During the first six months after a major OS release, the three latest major OS versions are supported. New Pillarbox releases made during this period are compatible with these three versions.
• Six months after a major OS release, we drop support for the second to last major version. New Pillarbox releases made after this date will therefore be compatible with the last two major OS versions.
• Individual Pillarbox releases are supported for critical fixes during one year after their release date:
  • Critical updates will not be published automatically but upon explicit request and will preserve the original release minimum deployment target.
  • Critical fixes can only be requested for existing products. New products are supposed to use the latest Pillarbox version right from the start.
• Pillarbox forks are not endorsed and won’t receive any support.

In practice this means that major OS versions are covered for two and a half years by regular updates, and up to three and a half years by critical updates.

Example

Let us assume that iOS 14 will be released on September 16, 2020. This means that:

• Each new release of Pillarbox made until March 16, 2021 will support iOS 12 as minimum deployment target, thus running on iOS 12, 13 and 14.
• Each new release of Pillarbox made after March 16, 2021 will have its deployment target set to iOS 13, thus running on iOS 13 and 14.
• If a team discovers a crash with some Pillarbox version 3.1 it uses in an existing product, and if this version was released February 3rd, 2021 with iOS 12 as minimum deployment target, it might request a critical update for this version (still compatible with iOS 12) until February 3rd, 2022. After this date, the team will need to update to a supported Pillarbox version first.

Adoption of semantic versioning

We follow strict semantic versioning (https://semver.org/):

• The major version number is incremented with breaking changes.
• The minor version number is incremented for releases with backwards compatible added functionality.
• The patch version number is incremented with backwards compatible bug fixes.

Additional rules:

• Semantic versioning does not explicitly cover what should happen when the minimum deployment target is increased. The change is not breaking but not as straightforward as a patch. Therefore if the minimum deployment target of a Pillarbox changes we will increase at least its minor version number.

Critical vs. non-critical issues

The following are considered critical issues: