We are pleased to introduce Semantic Versioning and release channels to Snyk CLI from v.1.1291.0 onwards. In this blog post, we will share why we are introducing these changes, what problems these changes solve for our customers, and how our customers can opt-in according to their needs.
What problem are we solving, and why?
Snyk CLI was introduced to the World Wide Web and security enthusiasts on October 2, 2015, as v0.0.0-pre-alpha release. In the past eight years, we released Snyk CLI nearly two thousand times — and more than eleven hundred of those releases happened in the last three years. That’s one release every thirty-two hours, signifying our customers’ growing needs as well as the pace at which we operate to meet those needs at an enterprise scale. With increasing demand, the complexity, reach, and impact of our fast-paced code changes increased, too.
On the one hand, delivering fixes and changes rapidly ensures every Snyk user has access to our latest capabilities. On the other hand, our user research with enterprise customers highlighted that receiving frequent Snyk CLI releases introduced governance and compliance overhead. As we observed these recurring signals, we recognized the need for a change that elevates the Snyk CLI experience for our customers and our end users — from developers to DevSecOps.
As a security gate, the Snyk CLI is the linchpin of our and our customers’ development ecosystem. A disruption to the Snyk CLI causes direct disruption to our customers' build pipelines, impacting their business commitments and their users’ experience too. Snyk acknowledges the trust that our customers put in Snyk with utmost sincerity, and we feel there is a need that remains unmet, which is the flexibility to choose a sustainable pace.
This is why we are introducing the following changes to the Snyk CLI from v.1291.0 onwards:
- Semantic Versioning to Snyk CLI releases
- Different channels that allow our customers to opt-in per their preferences and need
What do these changes mean for our customers?
Releases
Snyk CLI follows the industry standard Semantic Versioning three-part notation, as shown below.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make [breaking] changes
- MINOR version when you add functionality in a backward-compatible manner
- PATCH version when you make backward-compatible bug fixes
Additional labels are added for CLI releases as needed based on the standard.
In Snyk CLI’s context, we define a breaking change as one that could break automated workflows and cause failures in your existing working setup, such as CI/CD integrations. Breaking changes will be indicated by incrementing MAJOR and mentioned in the release notes.
Some examples of breaking changes include:
- Deprecating or changing output fields, field names, or environment variables
- Introducing mandatory configuration changes
- Changes in error or exit codes
Occasionally, depending on the nature and impact of the issue at hand, we will also release hotfixes, resulting in an increment in PATCH.
Channels
We are introducing different channels, enabling our customers to choose a channel that fits their needs and preferences.
To the customer, selecting a channel means selecting the stability level and pace of code changes they want to use:
-
preview- “pre-release” builds are deployed regularly up to multiple times a day and contain the latest changes
- Version Pattern:
v{MAJOR}.{MINOR}.{PATCH}-preview - Cadence: Varying
-
Availability:
-
rc- “release candidate” pre-releases are deployed at distinct points in time and contain a version of the CLI that is expected to be promoted to stable after additional testing.
- Version Pattern:
v{MAJOR}.{MINOR}.{PATCH}-rc - Cadence: every 8 weeks, 2 weeks before a stable release (hotfix releases possible)
-
Availability:
-
stable- Stable builds are deployed at distinct points in time after being additionally tested and considered stable.
- Version Pattern:
v{MAJOR}.{MINOR}.{PATCH} - Cadence: every 8 weeks (hotfix releases possible)
-
Availability:
- https://github.com/snyk/cli/releases/
- https://static.snyk.io/cli/stable/
- https://static.snyk.io/fips/cli/stable/
- npm
- brew
- scoop
- Snyk-images
Snyk recommends opting into a stable channel for the following reasons:
- A stable build is tested extensively over the course of 8 weeks, during which Snyk development teams use the CLI during the SDLC process
- Accompanying release notes to help you decide which version best suits your needs
However, customers who would like to receive code changes as soon as they are merged can opt into the preview channel. Please note that Snyk does not offer support for the preview channel, and we expect known issues to be present in it.
Tip: Our existing customers who opt into the previously known latest channel will automatically opt into the stable channel. Behind the scenes, we mirror the latest stable version to avoid disrupting our existing users. However, as shown in the next section, we encourage you to switch to the new release channels.
Selecting a channel from the IDE
Please choose a CLI release channel via the drop-down shown in the screenshot below. Our users can switch between release channels, for example, switching to release-candidate (rc) to receive a hotfix. This functionality is available in IntelliJ IDE. We will be extending this capability to other supported IDEs soon. The default channel for all IDEs is the stable channel.
Conclusion
Nearly two thousand releases later, helping our customers and developers deliver secure code has remained a rewarding experience for the Snyk team. We remain committed to enriching the Snyk CLI with the aim of delivering an exceptional developer experience that allows developers to do their jobs well at a sustainable pace.
If you would like to share feedback or participate in our user research, please contact our support team, your account manager, or the Snyk CLI product manager. We look forward to partnering with you to craft the Snyk CLI’s future state.
Top comments (0)