Versioning change (for API update)

[masklinn]

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]

So one advantage of option 2 is the versioning could be "floaty" so it updates on its own kinda, and furthermore it would be possible to release periodic alphas / prereleases of uap-core, as the official releases are cut pretty infrequently (see #211 for an exemple of motivation), though I'd have to look at how that works exactly e.g. is it possible for a consumer of the package to get onto the pre-release stream without "normal" consumers being affected? So e.g. we could have a monthly (?) release of a precompiled uap-core called 0.19.devX, where X would either be a numerical increment or a YYYYMM date (so e.g. 0.19.dev202411).

It could also be easier for debian to do the thing.

And finally the legacy package could be updated to make use of the split sub-package as well.

The drawback is I'd have to understand how to split the package into two somehow? This might also complexify tests, as they use regexes.yaml in both raw and precompiled forms.

Also the packages would be co-dependent: ua-parser depends on the precompiled expressions, but the precompiled expressions depend on ua-parser (to know what types to initialise).

[masklinn]

Whelp, kinda hitting a few issues on the splitting:

• because the dependency being extracted is entirely virtual (the package itself is created at runtime, then it's compiled into a wheel) a preprocessing step is needed to run the test suite, but tox does not support preprocessing steps (would require a tox plugin)
• the test data and regexes.yaml are paired and updated in lockstep, so testing with precompiled data and an uap-core submodule does not guarantee they're in lockstep, on the other hand we want to test precompiled data (and have to for the legacy tests) otherwise there's no guarantee they work...