Flagship Version Support Policy
Flagship follows the Semantic Versioning specification for new version numbers. In short, Flagship versions have the format xx.yy.zz where xx is the major version number, yy is the minor version number, and zz is the bugfix number. Per the specification, any new version will be backwards-compatible with the previous version unless the major version number is incremented.
If only the patch version number is incremented (e.g., 9.0.0 → 9.0.1), a bugfix has been introduced that will not change existing functionality.
If the minor version number is incremented (e.g., 9.0.0 → 9.1.0), a new feature has been introduced that will not change existing functionality.
If the major version number is incremented (e.g., 9.0.0 → 10.0.0), a change has been introduced that breaks existing functionality or requires changes to end products that implement Flagship.
Notes for all changes can be found in Flaghip’s README file: https://github.com/brandingbrand/flagship/blob/develop/README.md
In addition, all major releases have a page in the Flagship wiki describing the changes and the steps developers need to take to update to the corresponding version: https://github.com/brandingbrand/flagship/wiki#major-flagship-releases
The development team intends to release two major versions of Flagship per year, the first approximately at the end of Q1 and the second in the end of Q3. Each major release will be supported for 365 days after initial publication. Once a new release is live, the previous release will be moved to maintenance support, with updates being limited to bug fixes and security patches for the remainder of its support period.
The following diagram illustrates the release schedule for the next two years as of this writing:
Major releases typically add support for the newest stable version of React Native as well as other core dependencies such as React Native Navigation.
While updates that would require significant changes to Flagship apps will be limited to the aforementioned schedule, circumstances may require additional breaking releases to be made outside of the normal timeline. For example, Flagship 8.0.0 was released to implement a newer (breaking) version of CocoaPods due to issues with the original CocoaPods registry.
Should a feature be scheduled for removal from Flagship, the following process will be followed when possible:
A deprecation warning will be introduced in the next major release of Flagship The deprecation will be clearly noted in the release notes and Wiki The feature will be removed in the following major release of Flagship
Per the release schedule, there will typically be 6 months of warning before a feature is removed. Please note that due to extenuating circumstances a feature may be removed without receiving a deprecation warning first, but these changes will always occur within major releases of Flagship and will be clearly documented.
Flagship packages are published separately to NPM so that apps only need to pull in the dependencies that they need. While it is possible to have different versions of different Flagship dependencies, please be advised that Flagship is only tested with packages on the same version and therefore it is highly encouraged that your apps do the same.
For example, if you need to update @brandingbrand/fscommerce to 9.4.2, you should update all other Flagship dependencies to 9.4.2 at the same time.
To report issues or offer suggestions, please log an item in Flagship’s issue tracker: https://github.com/brandingbrand/flagship/issues
To privately contact the Flagship team, or to report security issues, please email flagship@brandingbrand.com.