This document outlines the support & deprecation policy for the Button Publisher SDK (“Button SDK”.)
Making version support for the SDK explicit means that Partners can always expect full functionality & support on versions of the SDK that fall within the support window. It also means that Button can expect to be able to keep a limited number of versions of the SDK in the wild at any given time — making it easier to evolve the product and deliver new features!
We want to make it easy to update the Button SDK regularly, so we follow the practice of Semantic Versioning.
In SemVer, a release version is always in the form x.y.z, where updates can assume no changes in code as long as x is constant.
With Semantic Versioning, it is always safe to update to any SDK version with the same Major version number without making any code changes. This is why we recommend including the Button SDK with a fuzzy-matched version of the current major version.
Button ~>5.0 // version >= 5.0 & < 6.0
New minor versions will never remove a method, but it may deprecate them. Deprecation means that a method is marked for removal, likely in the next major version.
In major version changes, methods, objects and semantics could change so it’s important to update major versions explicitly and carefully. It’s possible that an existing implementation of the Button SDK could stop working, or even not compile after a major version update. Where this is non-trivial, Button will create a migration guide.
A supported SDK version is guaranteed to function as it did on the day it was released, with no additional work by the Partner.
If an issue (new, or pre-existing) is discovered that is present in a supported SDK version it will be investigated as a P1 issue. If it causes an app crash, it will be investigated as a P0 issue.
Note — Bug fixes and fixes to security issues will not be backported to minor versions, but will be available in the same major version. e.g. An issue found in
v5.10.1, would be resolved in a new version that is likely much greater, but is drop-in compatible e.g.
v5.31.0. If it is present in a later major version, it would be fixed there too (e.g. in
When Button introduces changes in the SDK that require meaningful Partner effort to upgrade to the latest version, Button will mark the previous version as a Long Term Support version of the SDK. This will happen for most (but not necessarily all) major version updates of the SDK e.g.
A Long Term Support SDK version will be guaranteed to function for 1 year from its release, at which time Partners will need to upgrade. This allows Partners time to schedule and plan for any necessary work (usually small, but not always trivial.)
Button will notify Partners when a version of the SDK that is in use is approaching the end of its support period.
A version that is no longer supported may continue to function, but we do not guarantee it, and could make choices that negatively impact the behavior or performance of a version of the SDK that is no longer supported. In practice it means that this version of the SDK is no longer tested during all API and system changes, and may even be intentionally disabled.
In certain scenarios, when working on major new functionality that we want to preview with our partners before fully releasing we will issue
beta releases of the Button SDK.
These will be distributed normally, but with a version number that indicates that it is a beta release.
Beta version in semantic versioning e.g.