Prereleases standard

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.

Screenshot 2024-03-14 at 16.30.23.png

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.

Screenshot 2024-03-14 at 16.20.32.png

Creating overrides for prerelease versions 

When a developer requests a prerelease version of a package, you may still want to create an override for this release to be approved in your catalog. The reason to do this is that you may have a business decision that states a particular pre-release stream is not a concern—or in some cases, a package may not be using a traditional form of versioning, so you want to override the decision that your standard configuration made on your behalf.

When completing a task, an override can be created for the specific version mentioned in the task. If you would like to allow prereleases for an entire package, use the manage overrides page mentioned below. We recommend managing overrides in the standard's manage overrides page.

  1. Navigate to the Standards page
  2. Find the Prereleases standard
  3. Select Manage overrides
  4. Click on "Create new overrides" and fill in the appropriate information
  5. On this page you can view, edit, and add overrides

Screenshot 2024-03-14 at 16.29.45.png

Screenshot 2024-03-14 at 16.28.04.png

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.

Articles in this section

See more