Improving version guidance — please help!

Back in July, my coworker John published a post here about version scheme and release support status. The goal was to get a better understanding of how maintainers think about the versioning schemes that they use for their packages, so that we could better direct subscribers to use the maintainer-recommended version of those packages.

Why? Not only will this help improve the health of our subscribers’ codebase (using the recommended versions!) but it would also (hopefully) improve life for maintainers—many of whom effectively support old versions—by consolidating users onto a smaller number of supported versions.

We currently use the Release Streams task to try to do this, but, frankly, it doesn’t work. As you probably know, the Release Streams task is really confusing, and is basically a giant wall of text.

In fact, this task has the lowest completion rate of any task on Tidelift: 58% completed, when I checked earlier this week :confused:

To solve this, we’d like to split the Release Streams task into two: a Version Scheme task, and a Security Updates Policy task.

Shown below, the Version Scheme task will ask you to identify the scheme you use for your package. Many packages use semantic versioning, but many don’t. Once we clarify this, we’ll be able to better understand how you approach versioning.

After completing the new Version Scheme task, you’ll be able to complete the Security Update Policy task (below). Here, we’ll look at all the different version streams (identified in the Version Scheme task) and ask you to mark how you plan to respond to security vulnerabilities on them.

Before we release these new changes, I’d love some feedback from you all (especially some of our many new lifters!):

  • Do the versioning schemes shown in the Version Scheme task include how you approach versioning for your project? If not, what are we missing?
  • Given that we’ll want to keep the Security Update Policy up-to-date in the future, what would fit best in your workflow to validate this open a new release? GUI? API? Something else?

Thank you, as always!

2 Likes

Looks sane.
Versioning: yes, semver
Security: GUI, prompted when release a new (major) version

3 Likes

I’m going to miss the “Only the latest version is supported” option if that goes away!

Hypothesis uses semver, but updates very often - averaging around once per day. https://libraries.io/pypi/hypothesis/versions

We also need to distinguish between “we will only fix bugs if they are present in the latest version” and “it is no longer safe to use versions older than [some security issue or critical bugfix]”. The former does not imply the latter, and our advice for most projects is “pick an update cadence that works for you and stick to it; we update our pinned versions weekly” :stuck_out_tongue_winking_eye:

3 Likes

One of the things we were going for in the new mock is to change from “supported” (unclear meaning) to “security update policy” (much narrower) - is that what you meant in clicking “only the latest is supported”? i.e. for Hypothesis, would you ever backport a security fix to an older release stream?

It totally makes sense for this screen to allow people to input a “policy” like “only latest stream has updates” or “only the last 2 have updates” etc., it’d be good I think to collect what policies people are looking for; “only latest” is a common one for sure.

Do any projects have a time-based policy, like “each stream is supported for 6 months” or something like that?

We only ever make releases based on the latest version, and no real concept of a release stream.

No backports for any reason without specific funding, which hasn’t happened so far - we find that with careful forward and back compatibility we don’t really need them. (and apparently nobody else wants them enough to pay either)