Agree it would be nice! As a maintainer, but not a user/needer of this package I would love someone to volunteer to do the releases etc.. maybe you're up for it?

I can easily do it if master is green. For the longest time is was broken if we bumped uap-core, and I didn't want to invest the time to figure out why. So if we're all green now, it's easy for me to just tag and upload.

Also fwiw, Sentry (https://github.com/getsentry/sentry) still depends on this library and we use it heavily, so we do have vested interest in keeping it going. We've just apparently not had any issues or complaints for the latest version.

I also feel like, this would be valuable as some calver versioning scheme since semver doesn't really make sense if all we do is bump a sub repo periodically.

I'm open to whatevs =) Since you depend on it I'd prefer you to have it serve your (and Sentry's needs)

I think I'm going to be updating this to calver this week. It's a trivial change, but then I can better automate just bumping versions monthly or on some more regular cadence. Might even play with writing a bot to do it. Probably won't though since I'm lazy, but should make it easier all around to keep more up to date.

any updates here?

@dgoldstein0 since this issue was opened the project has pretty much been following the request (of matching uap-core's version) so I'll close this.

Eventually I'd like to decorrelate the two (so updates to the library can be correctly reflected in its version number, especially as I'd like to eventually release a 1.0) but I've yet to see a scheme which made sense. I'm not too fond of calver, let alone periodic tagging, as the library does not change much (ignoring the changes I'd like to eventually implement, which should be a big thing but then back to a very stable state): during the loss of maintainership the main issue was really the lack of updates to uap-core.

I've been considering splitting the package into two, with the precompiled uap-core being published independently, and thus theoretically being able to mix and match versions of -core and -python, but that seems a lot of complexity.

Yeah.... I have yet to see any good handling of multiple versions in one version number either. The typescript ecosystem especially has this problem, where npm package foo may have a corresponding @types/foo package. Typically the @types/foo and foo packages share a major version number but get out of sync in the minor versions. As a result, @types/ packages don't really follow semver semantics, as improvements to types can themselves be breaking changes but syncing with the library's major number means they can't convey that.

In the case of this library... uap-core has pretty extensive test data for each uap-* implementation to check against; a minor update to uap-core could require code changes for the tests to pass for any particular language, though this will mostly be in fixing edge cases. I suppose it might be theoretically possible to make each uap-python support multiple uap-core versions, but that seems like an unnecessary amount of work. Some sort of automation that pulls, updates, and tries to publish a new version of this package every time uap-core is published seems likely simpler. With manual intervention required when tests find new issues.

Anyhow I don't particularly care if the version numbers are kept in lockstep, just that if uap-core updates, that there's a new uap-python version with the updated uap-core, and that we can figure out the mapping of versions - a lot of the value of the uap ecosystem is being able to have the same user agent parsing logic across multiple languages, and to be able to deploy updates as new browsers become available by fixing one central detection algorithm.