Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versioning change (for API update) #146

Open
masklinn opened this issue Nov 7, 2022 · 0 comments
Open

Versioning change (for API update) #146

masklinn opened this issue Nov 7, 2022 · 0 comments
Milestone

Comments

@masklinn
Copy link
Contributor

masklinn commented Nov 7, 2022

Aside from actually designing the API, that's probably the biggest issue with #93 (#116): how to update the version?

Per #75 it's clearly important to have a good versioning scheme, and to reflect the version of ua-parser/uap-core since that's, well, the core.

But PEP 440 doesn't really provide a multi-versioning scheme:

  • local versions (+) are specifically for locally patched versions (in other ecosystems it's used for multi-versioning)
  • epochs (!) are for completely switching up the versioning scheme, in order to ensure ordering remains consistent when switching between e.g. m.m.m and date-based versioning schemes

The two contenders then seem to be:

  • extending / appending the version numbers as the "version segments" are illimited, e.g. 1.0.0.0.16 would be uap-python 1.0.0 using uap-core 0.16, this would allow users to select data versions within API versions, not the reverse but that doesn't seem very useful
  • splitting the package in two independently versioned libraries, one which would only expose regexes.py and the other the API and the matching machinery proper

The latter would increase the complexity (and moving parts), though it would selecting things more finely. However it's not clear that this division would be correct: if we start e.g. accelerating the matcher via a native implementation, the data from a ua_core.py package might not be used at all anymore.

On Calver

I want to explicitly reject calver as it was mentioned in #75: I don't think it's a good fit, calver is not useful for uap-python itself as the releases are irregular and mostly contingent on uap-core, but at the same time would not allow cleanly updating the API (#93), the library component makes the information of a semver version at least somewhat useful (though how hard semver principles are respected can be complicated).

uap-core could independently adopt calver, which would be a concern for the 0.x releases of uap-python, but probably not otherwise problematic (technically calver works fine in PEP 440, the only issue is switching from calver back to semver, as the version number has to regress, that's what epochs are for). It's not clear how good it would be though, as -core releases are also somewhat erratic, and it's not entirely clear what value date information would provide. The question would also come of whether calver releases would be as needed (though at most once a month) or at hard-set interval (à la ubuntu), possibly delaying data releases for users.

@masklinn masklinn added this to the 1.0 milestone Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant