Lifter Version Guidance - Versioning Scheme & Release Support Status

Hi, all. We’re continuing to work on improving the lifter experience, to make sure subscribers have ever-improving confidence in the packages they’re supporting. One of the areas that we want to improve upon next is version schemes and release support levels.

Right now, we’re assuming all projects use semantic versioning, and we have a task called Release Streams which defines how you’ll support older versions of your software. This task currently assumes the standard SemVer approach of major versions breaking compatibility, but also allows for minor versions being incompatible for alternative versioning approaches. Each “stream” as we’re calling it has a level of support: prerelease, long-term support, deprecated, or “use until newer/safer release is available”:


We’ve learned a few things since then:

  • Enough packages use something different from pure semantic versioning that we need to handle those schemes better.
  • The current interface for hinting to subscribers what versions you’ll support needs to be clearer.
  • We need to support more options for offered support levels.
  • We were also creating separate release streams for versions lower than 1.0.0. Under SemVer, any releases lower than 1.0.0 are the same as a prerelease, so there’s no way to give subscribers any assurances with those versions.

So here’s what we’re thinking, in mockup form. We want to both expand upon and simplify this task. First, we want to know what scheme you’re using for your package versioning, if it’s not pure SemVer (and if it’s something we don’t support yet, we want to figure out how to do so!). We’ll also show you, based on that version scheme, where we figure your releases fall into groups, to make sure we have it right:

Second, we want to rotate around the Release Streams view into a much easier-to-scan table, with some improvements on defining unsupported versions and with a new option, defining what groupings of releases you’ll support for subscribers who use your software. Here’s a mockup:

We’re still refining the idea, and we’d like to get your feedback on how best to help you define your projects’ levels of support.

Some specific questions:

  • Do you use a non-SemVer version scheme and how would you describe it?
  • What do you find clear and unclear in the above mockups?
  • Do you know what answers you’d give? Are you wanting to give an answer other than the options available in the mocks?

Leave a comment below with your thoughts!

3 Likes

FWIW, I don’t view incompatibility as a binary thing. I use a style close to SemVer where a MINOR bump can include an incompatibility if the chance of the incompatibility affecting anyone is very small.

The Security Update Policy looks good.

1 Like

I second that. That screen looks very simple and straight-to-the-point. Looking forward to using it!

1 Like

I just released a major version, so I have a specific question as I have been thinking about support.

I do not intend to fix bugs in the old version stream.
I do intend to fix security vulnerabilities in the old version stream.

Does this breakdown fit into the new scheme? (I think yes, since the “Versioning Scheme” and “Security Update Policy” are separate. I just want to confirm since I want to convey the right information to subscribers!)

You have it right - the rationale for making the revised page specifically say “security update policy” is to clarify that it’s only about whether you’d backport security vulnerabilities to the old stream, and not about other kinds of fixes. In the current “release streams” task that this would replace, it’s safe to assume the same meaning.

1 Like

Here are some additional tweaks to the versioning scheme page. A lot of the text could probably be hidden by default behind a help icon or “more info” kind of deal.

1 Like