I don't understand the current overall intention of releases

[nilsnolde]

Recently a monthly release GHA was added. Is there still going to be tagged releases @DennisOSRM ? I guess not, since that'd heavily confuse package managers. If monthly is the only future release schema, don't we lose a lot of implicit information? It doesn't implicitly say if it breaks smth.

I can see https://github.com/Project-OSRM/osrm-backend/blob/a27573f34a6ecddd79140ed81a121fa0e99f8297/docs/releasing.md, which details what the monthly releases should mean. Is there some magic hidden in the shell code of that GHA? To me it seems that scheduled monthly releases don't know if they're breaking the graph build or not? So as a consumer, every month I should rebuild (and re-distribute) the service's OSRM installation to not potentially break on new graphs that are build on some central server with the newest OSRM version?

I guess I'm questioning the overall versioning approach.. IMO date based versioning makes sense for things like SSL certificate packages (or OSs apparently), where date matters more. I think the (more) semantic versioning from before made more sense. One option could be to have GHA raise a PR to change the version monthly/quarterly and the reviewer can decide if it'll be minor or patch version, depending on whether "service worker" rebuilds are necessary. I can imagine that to be critical in quite a few situations. It's for sure easy enough for anyone serious enough to check that before upgrading, but no one would have to with the previous schema.

[DennisOSRM]

Thanks for raising this. It's a worthwhile topic to discuss. I think these are exactly the right questions. I broke down the various topics I read into your post into individual sections.

Tagged releases: Yes, the monthly GHA creates tagged releases (vYY.MM.PATCH), so package managers and pinned installs continue to work as before. The goal is to always be upgrading. Just like Chrome browser does.

On the versioning philosophy: The core argument for time-based cadences is that they decouple the release mechanism from feature semantics. Chrome ships every four weeks regardless of what landed; C++ ships every three years. Herb Sutter's case for this model is that semantic version numbers create wrong incentives. You either hold releases hostage to feature completeness, or you inflate minor/patch bumps to hit a cadence anyway, which erodes the signal. The version number stops meaning what it claims to mean. A date just means "this is what existed at this point in time", which is always true.

What CalVer doesn't give you: You're right that the version number itself carries no signal about graph compatibility. That's a real tradeoff, and I'm not pretending otherwise. The old semver scheme at least gestured at compatibility through major/minor bumps -- even if in practice OSRM's semver wasn't applied with the rigor that would have made that signal reliable.

And actually, semver was never sufficient here to begin with: any change to a routing profile also requires a full graph rebuild, regardless of whether the software version changed at all. That's a dependency semver can't capture, because it lives outside the version number entirely. Rebuild requirements in OSRM are fundamentally a two-dimensional problem: Software changes and profile changes. Collapsing that into a single version number was always a simplification. And the other side of the spectrum to start versioning profiles is wrong for a number of reasons.

What we're committing to instead: The version number encodes when; the release notes encode what changed and what it means for you. Old versions have no support and arguably won't be getting any. The default answer will always be to upgrade to the most recent release. A bug in a previous version won't get fixed in a point release, if it's not present in the main branch anymore.

A better long-term solution: The right fix for the rebuild-detection problem is to version the graph format itself. If the engine embeds a format version and refuses to load graphs built against an older one, you get an explicit, machine-checkable signal at startup. And no reading of release notes required. That's worth building independent of whatever top-level versioning scheme we use, and it would make the "do I need to rebuild?" question answerable without any human judgment in the loop. Arguably, the answer to rebuild should always be yes.

On your PR-based suggestion: I like the intent. The challenge is that a human review gate on the version bump adds a synchronization dependency to an otherwise fully automated pipeline, and those gates tend to slip. I'd rather make the compatibility signal explicit and machine detectable than make it load-bearing in the version number itself.

[nilsnolde]

I'd be worried though about the additional complexity in combinations of data, graphs, runtime, etc. That blows up quickly.

what do you mean exactly? complexity to guarantee (forward?) compatibility of all those things between minor versions?

[nilsnolde]

for context: I'd be very interested in graph forward compatibility so I can always build graphs with the newest version, distribute them and don't have to care which version the "client" is running.

[DennisOSRM]

I'd be worried though about the additional complexity in combinations of data, graphs, runtime, etc. That blows up quickly.
what do you mean exactly? complexity to guarantee (forward?) compatibility of all those things between minor versions?

Not the implementation complexity of guaranteeing compatibility – more the support surface that opens up once you have independently versioned artifacts. People will run mismatched combinations, and when something breaks they won’t know why. Half the resulting issues will be “graph built with format v3, runtime expects v4” reported as mysterious routing failures. Multiply that across OSM data vintages, profile variants, and binary releases and you get a long tail of one-off support cases that are each individually trivial but collectively a grind. A hard startup failure with a clear error message mitigates the worst of it, but you can’t close off all the edges.

[nilsnolde]

I really don't have enough context on osrm graph builds to have an informed opinion/argument.. I'll keep this topic in mind for the upcoming exploration.

at least over in valhalla I can say it requires quite some attention from reviewers, we currently do not/hardly have programmatic checks in place. however, I'll (hopefully) build a QA/QC tool within upcoming GSoC with a student, which mainly aims at detecting PR/master diffs, but will implicitly also test bwd/fwd compat: valhalla/valhalla#5899.

[nilsnolde]

actually such a tool could be easily extended to support OSRM, it should be generic enough. we could even use osrm response format for valhalla in the gsoc project (generally more useful for real-time guidance I think), then it should really be minimal changes.