Define parse_version for broad compatibility with packaging

[goerz]

Closes #27

[codecov]

Codecov Report

Merging #32 (12d7c2a) into master (a3051b3) will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #32      +/-   ##
==========================================
+ Coverage   96.46%   96.59%   +0.12%     
==========================================
  Files           6        7       +1     
  Lines         368      382      +14     
==========================================
+ Hits          355      369      +14     
  Misses         13       13              

Impacted Files	Coverage Δ
src/docs_versions_menu/version_data.py	100.00% <ø> (ø)
src/docs_versions_menu/folder_spec.py	100.00% <100.00%> (ø)
src/docs_versions_menu/groups.py	100.00% <100.00%> (ø)
src/docs_versions_menu/parse_version.py	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[goerz]

Well, switching from packaging to packvers seems like it should do the trick.

@klauer, @awoimbee, @ZLLentz: Any comments? Should I merge and release this as v0.5.2?

[ZLLentz]

I'll drop these links for the context on packvers:
pypa/packaging#530 (comment)
pypa/packaging#530 (comment)

I think it's a good solution since it covers all the current use cases and doesn't require a big rewrite. It'll be nice to be able to install this alongside packages that require the most recent packaging versions 👍.

[klauer]

I admittedly don't fully understand the need to retain the legacy version parsing. However as it seems to be a crucial part of your workflow, @goerz, I think this is a mutually-agreeable solution and am on board 👍

By the way - we'll have to update the README indicating just how many repos use this library one day. In our organization alone, we have about 100 repositories using docs-versions-menu. Overall we're very happy with it. Thanks again for your great work here!

[goerz]

I admittedly don't fully understand the need to retain the legacy version parsing. However as it seems to be a crucial part of your workflow, @goerz, I think this is a mutually-agreeable solution and am on board 👍

It's required because I'm putting all folder names in the gh-pages branch (or wherever the docs-versions-menucommand runs) through that parser. This is to sort and categorize the folder names. The folder names will usually be the names of tags (released versions like v0.1.0) or branch names. The LegacyVersion specifically handles all branch names (master/main, or whatever other branches might be set up to generate documentation). Thus, the name LegacyVersion is actually a bit confusing: this isn't about some "legacy" versioning convention, but about arbitrary branch names that aren't versions at all. It's probably a good idea to make the intent a bit more explicit, and hence I've added 34489f6.

By the way - we'll have to update the README indicating just how many repos use this library one day. In our organization alone, we have about 100 repositories using docs-versions-menu. Overall we're very happy with it. Thanks again for your great work here!

Wow! I'm glad it's getting some use!

[awoimbee]

Thanks !

[goerz]

Just for completeness, pypa/packaging#669 is quite interesting and points to packaging_legacy as yet another workaround for the removal of LegacyVersion. Alas, I'm perfectly happy to side-step the whole drama and implement the required functionality in docs_versions_menu directly. Hopefully, packaging will be more stable in the future, but if not, I'll just keep moving stuff into here.

[klauer]

I understand the issue better now and like the approach you chose here, sticking with packaging and extending it for the purposes of docs-versions-menu.

If/when the upstream library API changes, it can be revisited then.

[ZLLentz]

The final approach here is clean and the code's intent is clear, I like it a lot