fix: use url.Values for Qualifiers - #57
tommyknows wants to merge 1 commit into
Conversation
|
Releasing a v0.2.0 would break our current release scheme. We map the minor version to the current purl spec version (probably not the best way and we should aim for a v1 instead.. I know). |
BREAKING CHANGE: This commit removes all the custom qualifier-logic that existed in order to keep the ordering of the qualifiers. The spec says: > sort this list of qualifier strings lexicographically However, it doesn't say anything about the ordering within the typed representation. Using `url.Values` through a type alias gives users an easier way to access specific values and removes code that we now don't need to maintain anymore. See package-url#53 for more information.
|
Okay I've just rebased this PR. I'm not sure what to do with the versioning scheme / releases, so I'll leave it to you to merge this PR or close it! |
|
We could cut a v1.0.0 before merging this and then bump the major version to v1.1.0, but I am still not 100% happy about this. Mirroring Spec releases to the same version is very impractical, it might be better to create spec directories like: v1/packageurl.go and if a v2 drops we have a v2/packageurl.go. 🤔 This way we could uncouple the versions. |
|
I will open a separate issue for this and ask for some feedback from the other maintainers :) |
|
The code has drifted quite a lot since this PR was crafted. I'll close for now. Feel free to rebase and repoen! |
3 participants
BREAKING CHANGE: This commit removes all the custom qualifier-logic that existed in order to keep the ordering of the qualifiers. The spec says:
However, it doesn't say anything about the ordering within the typed representation.
Using
url.Valuesthrough a type alias gives users an easier way to access specific values and removes code that we now don't need to maintain anymore.See #53 for more information.
#53 briefly touches on the release process as well. Because this library is still in alpha-release (
v0.x.y), I don't think we need to bump the major version. Releasing av0.2.0would be fine according to the SemVer rules.I'm aware that this is quite a big change to the API, but I think better now than later :)