Deprecate `SEMVER` range type.

[oliverchang]

SEMVER was a special case we introduced early on in the schema. The difference with ECOSYSTEM was that we had required ECOSYSTEM types at the time to come with an exploded list of versions in the versions array. The reasoning was that it was difficult as a record consumer to make use of ECOSYSTEM version ranges directly, because there are many versioning schemes to implement. SEMVER on the other hand was well defined and had easy to understand rules, so it did not have this requirement.

We dropped this requirement in #18, as it turned out it was difficult also for record producers to reliably generate this data. This gap is now being filled by OSV.dev, which implements all the different versioning schemes to support version ordering an matching without requiring record producers to include an exploded array of versions.

Given the backwards compatible nature of the schema -- we can't just drop this type completely. What we can do instead is add text to recommend just using ECOSYSTEM.

@andrewpollock @darakian @taladrane

[andrewpollock]

I'm still determining how I feel about this...

On the one hand, supporting being able to explicitly state the format of the versions in a range seems more desirable to facilitate optimal downstream consumption of them?

I could see benefit to expanding the supported types, not shrinking it, but it's possible that clearly stating what assumptions downstream consumers should be making based on the ECOSYSTEM type may be a suitable alternative path.

[oliverchang]

Specifying the ecosystem inside package is essentially the same as specifying the format of the versions. An ecosystem itself defines the versioning scheme it uses.

It seems redundant to maintain a full list of versioning schemes here in addition to all the ecosystem definitions.

Or are there other cases where this is useful?

[andrewpollock]

Or are there other cases where this is useful?

The additional thought was around the (still theoretical) interop with the CVE 5 Schema (or the intent at least) and what's happening in CVEProject/cve-schema#362, namely if we want to be able to richly cross-convert to CVE, it would be better to be able to support maintaining fidelity.

[oliverchang]

Or are there other cases where this is useful?

The additional thought was around the (still theoretical) interop with the CVE 5 Schema (or the intent at least) and what's happening in CVEProject/cve-schema#362, namely if we want to be able to richly cross-convert to CVE, it would be better to be able to support maintaining fidelity.

Even in those cases, we could have the OSV->CVE converter handle this -- the ecosystem being the source of truth tells us which value to put in the CVE for the type. We should avoid adding redundancy to the schema and potentially making OSV harder to understand and produce.

I can see the need for CVE -- because they need to describe vulnerabilities in software that's not tied to a well defined ecosystem. But these would be out of scope for OSV.

What would make a stronger case in particular for OSV is if there are common cases where the versioning scheme is independent from the specified ecosystem.

[darakian]

It seems redundant to maintain a full list of versioning schemes here in addition to all the ecosystem definitions.
Or are there other cases where this is useful?

Another (currently) theoretical case would be to allow a project in some poorly defined ecosystem (say maven) to provide a project specific version representation and ordering. Basically to allow for an override on the ecosystem specific rules. Override might be the wrong term to use as well, maybe tightening or something.

Eg. If I am some maintainer of some software and I hold myself and my project to semver/whatever-ver but I happen to publish artifacts in a poorly restricted ecosystem then (assuming tools help me) I can express my vulns in a rich, automation friendly way.

Now, none of that tooling exists today and likely won't exist tomorrow, so should that change anything here? ¯\_(ツ)_/¯

So, with respect to having the ecosystem versioning be default and implicit; 👍
Seems like the right approach to me.

With respect to the list; makes sense to de-prioritize it to me, but I don't see the benefit of deleting anything. Seems like deleting isn't on the table, but if so then please ping me before hand so I can make a copy of the list 👀