Using release candidates or releases that are in beta poses a risk to your organization. These releases are still in early days of usage so they may have decreased stability and vetting, and may be subject to breaking changes. With the Tidelift Subscription, you can require the usage of stable releases by using the Prereleases standard.
How does Tidelift identify prereleases?
We identify prereleases by trying to recognize package manager conventions in the version number. Learn more about the conventions of some package managers below. Examples of prereleases would be 1.0.0-BETA1, 3.0-SNAPSHOT, 2.0-RC3, or 0.9.0 (in Maven)
Information for specific package managers can be found at:
Configuring the Prereleases standard
The prereleases standard will record a violation and deny the use of beta or release candidate releases in your catalog.
You can optionally choose to ignore unknown packages, which are often internal packages. We recommend turning this setting on.
If you feel that you need to manually review each release, you can request a task to be created. You should only turn this on if you want to review each release, and potentially allow a pre-release to be used, overriding your use of this standard. In order to allow developers to use a release that is flagged, you will need to create an override of the standard's decision, either by completing the catalog task workflow, or by managing overrides (see more below).
Finally you can choose to allow prerelease versions in your catalog, and only record the violations. We recommend turning this setting on to minimize your catalog administration work, ensure your developers can do their work, and also track any places in the organization where pre-releases are in use.
Managing overrides
You may need to allow something that the prereleases standard has not allowed. For example, a required package may have no releases that are not prereleases.
To do so, see Creating Overrides.