Enhanced documentation or support for deprecated/obsoleted packages

[monty241]

Based upon V2.0 of Semantic Version, there is no specific way to signal that a release numbering following Semantic Version is "deprecated", with "deprecated" meaning that it is end-of-life and users are urged to upgrade.

A deprecated/obsoleted product is still often fine for production use.

An alternative would be to use for instance "-depr" as a "prerelease", but that signals also a pre-release to for instance the related tools of NuGet. Build metadata would also be an option, which are new with 2.0.0, but less well supported.

For now, we are sticking to including "-depr" in the file name of NuGet packages, but having a version number without "-depr" in the NuGet package metadata.

It would be great when the standard could be extended to explicitly state how to signal that the whole library, package, executable or package is in an deprecated state.

Related:

• What does "issue a new minor release with the deprecation in place" actually mean? #325

[ljharb]

A semver version can’t ever change; it’s immutable. Deprecation status changes. As such, it’s not appropriate to couple the two - how to handle deprecation should be determined by an individual package manager.

[monty241]

Yes, that is correct (see https://semver.org/spec/v2.0.0.html#spec-item-3). Our releases, say 22.0.1 - 22.0.705, were production, but everything released AFTER the next major version hits the market is signaled as deprecated, so 22.0.706 - 22.0.813, are releases that are already deprecated on initial release, but serve to give users time to migrate to the next major release.

Similar to what Microsoft does with Extended Support and other End of Life Support packages.

[ljharb]

Interesting, that’s a very strange approach to me. Either way I’d say the deprecation status should always be independent of the version number.

[ljharb]

It seems like prereleases of the next major would be a clearer way to signal that, though?

[monty241]

Yes, I can imagine that it is atypical, but I see it often in business software (so large to very large software packages). Beyond that there are releases, there is even a ecosystem around dead software like Spinnaker Support that keep them alive say for five years after terminal releases.

Support is typically given only on some versions, typically in "Production" state, but when using deprecated versions it is a strong signal that a product has limited or no remaining regular supported lifetime.

A sample of this is the ESU ("Extended Security Update") program of Microsoft.

With often multiple major releases in the field, for instance 3 overlapping in varying grades of support, I don't know how to signal with the prerelease of the next major what major will be phased out.

[jwdonahue]

With the exception of prerelease, there's nothing in SemVer to express policies. That sort of thing should be handled at the package feed level, not in the version number. There's potentially infinite policies that might apply to a particular publisher's offerings, so no good way to standardize on that in a short, universally understood string.

I've seen some schemes in the past that encoded non-version information, along with the version string, mostly for ROMs or circuit boards, but they all have proprietary meanings.

[jwdonahue]

I would add that it's not always possible to know in advance, that a particular version is going to be the last of that series.

[monty241]

Yes, we are now using something proprietary. Unsure whether other publishers of large packages have the same itch.

Regarding knowing in advance: it is not possible nor desired to know in advance unless there is some kind of formal deprecation list or certification matrix employed by companies like Oracle, IBM or Microsoft. In our case, the deprecated state finds its way back in the legal agreements and product lifetime agreements.

[jwdonahue]

Having worked there most of the past 20 years, I can attest that Microsoft publishes end of life charts, for most of their major product releases, that specify target EOL's for the general public and expected extended service periods that may follow (for a fee). They have a history of giving in to pressure to extend the GP and ES periods, NT4 and XP being prime examples.

You might be interested in looking at VersionMeta and VersionSchema. They've been a work in (slow) progress for several years, but the goal is to break out of the one string for them all. With VersionMeta and VersionSchema, your automation can use build numbers for internal/external flight testing, SemVer for GP releases and you overlay human/machine readable definitions on the tags for things like what all those symbols in your SemVer build meta tag mean.

[jwdonahue]

In your case, if your package tools and feeds preserve the SemVer build meta tag, you could just add a +EOL or +FinalFix tag to whatever release you expect not to follow up with further bug fixes. That's the kind of thing you could easily fold into your contracts.

---

Even if retrospectively you realize 1.5.99 is the last one, you could still push 1.5.100 that only has the new build meta content and maybe an EOL.txt file in it.

---

If you're doing things correctly, your customers should automagically pick up all your patch level changes, because you've promised to only fix bugs therein and certain minimal level of quality. After that, their service requests will include that new version string and your customer support people can act on that information within your policy guidelines.

[jwdonahue]

Based on this MS-NuGet blog and some discussions we had with that team at MS a long while back (I was on the Windows build team then), I am pretty sure that the entire MS supported tool chain and feeds for nupkg's, has full support for build meta tags in the version string.