Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Versions start with v #1724
What does this PR do and why is it necessary?
Allows github versions to being with a "v". Up-to-date versions of pkg_resources, which OctoPrint uses to parse version strings, can handle version strings that start with a "v". But if the pkg_resources version that is available is old, OctoPrint uses the tuple returned to create a version string. But it handle the leading "v" like the new version and so github releases that start with a "v" will not be sorted correctly.
github themselves suggests putting a "v" in front of release names so it would be nice for OctoPrint to support it, too.
How was it tested? How can it be tested by the reviewer?
I tested this by uploading to my OctoPi, which has an old version of pkg_resources, and forced a check for software updates and it worked where previously it didn't. I also ran it from python to see if it works:
What are the relevant tickets if any?
This fixes OctoPrint/issues#1723 .
It isn't unprecedented, either. You can see that a leading v is supported in the new parse_version:
I think there's still a problem with the current implementation though and added a comment about that, could you take a look?
As a side note, the relevant code from the new parse_version has been moved here.
I also briefly wondered if it would make sense to extend the tuple handling to strip any parts that are prefixed with
I made the modifications necessary. This is the result of testing using an old version of setuptools:
This is the result on a new version of setuptools:
We can see that whether or not there is a leading v is ignored, both for old and new setuptools.
Looks fine now
I adjusted a code comment slightly (more as a reminder for me than anything - the code in the plugin manager is only needed for checking OctoPrint's own tags, which will always follow semantic versioning without a leading v, but it still makes sense to match behaviour of newer setuptools versions), added some whitespace and added you to
I'll also merge that up into
One thing: Github doesn't catch cherry picked commits on another branch and therefore will mark this PR as closed instead of merged. Don't be alarmed about that, your work has in fact been merged and it's just Github being a tad too inflexible here to cope with such situations. Thank you!