You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
+
) are specifically for locally patched versions (in other ecosystems it's used for multi-versioning)!
) 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 schemesThe two contenders then seem to be:
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 usefulregexes.py
and the other the API and the matching machinery properThe 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.
The text was updated successfully, but these errors were encountered: