search

VROOM-Project / pyvroom

Vehicle Routing Open-source Optimization Machine
BSD 2-Clause "Simplified" License
67 stars 14 forks source link

Tagging (again) #73

Closed jcoupey closed 1 year ago

jcoupey commented 1 year ago

Back in #22 I suggested a tagging scheme that would align version numbers with the upstream code to make life easier for users. This was based on our experience with vroom-docker which is a much thinner wrapper. But maybe this does not work too well here: since the python logic for the bindings is quite evolved, this project could also have it's own changes (major or minor) and patches.

An example of this is #71 where the previous 1.13.0 was aligned with upstream v1.13.0, but now 1.13.1 is not any more as there is not patch version upstream. On the other hand it's mandatory to tag the fix there. And if we were in need to issue a v1.13.1 upstream, that would become even more confusing.

My point here is what I thought would be a simple(r) tagging scheme will probably end up being quite limiting. Any opinions here?

nilsnolde commented 1 year ago

IMO both projects (bindings & docker) could use smth "non-semantic", e.g.

Though one'd have to check with PyPI's/setuptools_scm (or similar) requirements for the bindings. docker registries would allow for almost anything AFAIK.

jonathf commented 1 year ago

Pypi only accept SemVer so that is what we're stuck with.

The best we can do that gives a sane behavior with fixed patch release would be to use post releases: 1.13.0-postX. Not super intuitive for the user, and as Nils noted, a bit limited, but its good enough if version alignment is important.

jcoupey commented 1 year ago

I did not know about Pypi enforcing semver which is a binding constraint here.

Another solution would be that this project has its own pace and version numbers with the usual semver conventions, bumping the patch, minor, major versions based on changes on the bindings code itself. Then we'd simply provide a way for users to get the upstream version with some function/command.

This would add an indirection to reference the upstream version but would also clearly separate concerns. Also probably we'd be fine if mostly the latest pyvroom version provides bindings for the lastest vroom version, which is what most users would expect I guess.

jonathf commented 1 year ago

It is not going to be a perfect fit no matter what we choose. Unless anyone object, I will continue to use patch-version for updates, and reserver major nad minor as compatabillity layers to upstream vroom.