feat: precheck function for version consistency

[terriko]

• related: fix: create new version comparison function #3470

@antoniogi had an interesting suggestion during the code review in #3470, which is that we may be able to make a pre-check function for versions to see if they adhere to something that looks like a version schema that we can compare. I didn't want to delay that PR further but I think it's an interesting idea.

We're handling a few variants of version cases:

• comparison of . delimited numbers
  • e.g. 1.2.3
• comparison of numbers which may also include a few other special characters (_, -) (in kerberos and others)
  • e.g. 5-1.4
• comparison of numbers with appended letters that increase the version number such as openssl or libjpeg
  • e.g. 1.1.1g
• comparison of numbers with appended pre-release designators such as pre1, rc4, dev3
  • e.g. 7.8.9rc2

There may be other types of version schemas that we could support if we knew about them, and there may be opportunities for us to do better with what we've got. A precheck function might help us throw better version errors when we encounter schemes we don't know and help us figure out how to improve the function we're using.

A note on why the version compare function is urgent: currently we've frozen on an older version of packaging which you need to use for tests, but black now uses a newer version that we support, which means people need to run linters and tests in separate venvs, which is ok when you're using precheck because it automatically does that, but it's a pain when you want to run a tool manually yourself.

[rabroldan]

Hi there is it okay for me to try this one?

[terriko]

@rabroldan sure, have fun!

[ayushthe1]

hey @terriko ,I would love to take on this issue as it seems inactive for a while . Also, can you please give an overview of what needs to be done as it seems slightly confusing to me.

[terriko]

@ayushthe1 let's hold off on this one for a few days. I'm expecting that resolving #3657 is going to require some architecture changes that may alter what we want to do in a precheck.

[inosmeet]

Is this up for takes @terriko?
If so, I think we should start with Semantic versioning, as it covers most of the popular version naming schemas and we can add other as we go.
Also, what lifecycle would use this function?

[terriko]

Hm, so... we had to make a lot of changes to the version compare since this issue was filed and I'm thinking this may now be a waste of time.

Currently we can (and do) compare pretty much any arbitrary string. The system isn't going to throw errors.

Some of these could be nonsense compares if a version number includes a hash. So maybe it would be helpful to warn on hashes. But a lot of the real-world cases I looked at were things like semantic_version~hash so in practice the compare would do the right thing with the first part and that was good enough. There's very few cases where the hash is actually in the range provided by NVD. So I feel like warning constantly would be pretty annoying and not improve much of anything. Maybe it would be more useful to print a single warning when opening something like a SBOM file that the user might want to tweak to improve scan results, but even then I don't know.

I don't think there's any point in implementing a pre-check function until we have a better idea of user needs and what we're trying to get out of it. We don't have enough data for that right now, so I'm going to go ahead and close this until we know more about the problem space.