Remove semver.py and implement a much simpler version checker #859
Conversation
|
In retrospect I think hyphen ranges ex "2.1 - 3" would be good to support as well. In case we for example push API version 3 with a breaking change which extension developers could handle conditionally to support both versions. This is supported in the semver library we use now. |
|
👍 on supporting ranges. That seems like it would be enough to cover our usages generally. |
28a3711 to
3ca9134
Compare
…suited for Ulauncher's simple needs
3ca9134 to
efcc87b
Compare
|
I added support for hypen ranges, added tests and improved the documentation. Removed the API version bump. I think we will have to bump the API version major release instead, and I'd prefer not to do that yet for practical reasons (it will break all existing extensions for us while we're working on the v6 branch). So I added it to the "To do" list in the milestone description |
| if min_version[1] is None: | ||
| min_version = (min_version[0], 0) | ||
| if max_version[1] is None: | ||
| max_version = (max_version[0], 99999999999999) |
There was a problem hiding this comment.
Flawed logic, but it's an extremely safe assumption we will never reach a higher minor release number considering we only had two releases of the API so far 1 and 2 and no minor or patch releases at all.
Semver is way overkill for our needs. It is a 1000+ lines of code library that lets you specify versions in different ways like "1", "^1.0.0", "1.x.x", ">=1.0.0", and lots more ways that don't apply to how extension devs would use it. Even for software development/package management it's already mostly overkill, but it's useful to be able to lock the version and be more specific. For Ulauncher extension it doesn't make sense at all to use semver. There is only one logical way developers would want to specify versions, which is "I want to target this and all newer releases as long as they're backward compatible".
In addition it doesn't make sense to specify patch releases. In software development the version determines the version of the dependency that gets installed. This is what the patch version is good for, but Ulauncher extensions can't control which version of Ulauncher gets installed.
This suggestion changes the API version format to simply use numbers like "1" (shortcut for "1.0") and "1.1" etc. The semver library used before this PR actually allowed you to specify the versions like this also. The difference is that "1.0" or "1.0.0" in semver doesn't target "same or higher" minor versions. For that you would need to specify "^1.0" or just "1".
There are also only two versions of the API ever released. Version "1" (1.0.0) and version "2" (2.0.0), so the above should not be an issue for us.
There are also other possible incompatibilities, if a user would have specified complicated things that would make no sense targeting versions "older than" a specific version or "in between these two ranges" etc. The previous documentation recommended to use "^2.0.0" though, and that's what all extensions seems to do.
For the reasons mentions, this is technically this is an API breaking release, but it will not affect extensions, and bumping the major version number would hurt extension devs much more than help, so this is more of a pragmatic solution to a problem that at worst will affect a few odd extensions, and probably not even that.
For later I would like to also change the "versions.json" file. It's also overly complicated to have a special file for this, and even more to have to update this file which is supposed to be in the master branch, because you make changes to another branch. We could name git branches directly with the
required_api_versioninstead, or use git tags for this. Although this would not be possible to add while remaining backwards compatible.Checklist
./ul testis passing (the CI server will check this if you don't)