Dammit, sorry Julien, I'd forgotten about that issue - I'm not using the libosrm bindings directly, so this change slipped my mind.
If someone has time to fix the interface, we can release 5.24.0 to address it, and mark 5.23.0 as a dud. The interface change clearly breaks semver rules as it's not backward compatible. The alternative would be to release OSRM 6.0.0, but this feels like much too small a change to justify doing that. While I managed to find time to work through the release process, I do not have time to do any significant refactoring work :-/ daniel On Thu, Oct 15, 2020 at 12:38 AM Julien Coupey <o...@coupey.fr> wrote: > Hi Daniel and all > > Thanks for your work on this release, and all the various recent > contributions that made it possible. It's great to see a new OSRM > version, first one in a long time! > > I'd like to ask for a clarification though, if possible, on the status > of libosrm regarding this new version and possible future ones. There > are a couple of reports about the API breaking changes ([1] and [2]). It > means that projects relying on libosrm v5.* no longer compile with > v5.22, and now v5.23. This is a major problem for downstream users and > maintainers, especially since the OSRM release process has long been > adhering to the semver scheme. I only see two ways out: > > 1. The new v5.23 release somehow endorses the API change (after all a > fix now would also be a new change from the last two releases). In which > case downstream users will have to fiddle with adjustments based on > libosrm minor version. > > 2. This is considered as something that must be fixed at some point in > the future. Then no action is required downstream, except stating that > current libosrm versions are no longer compatible until a patch or new > minor version is released. > > Knowing which option is the most likely would definitely help. > > [1] https://github.com/Project-OSRM/osrm-backend/issues/5548 > [2] https://github.com/Project-OSRM/osrm-backend/issues/5741 > > Regards > Julien > > On 14/10/2020 23:14, Daniel Patterson via OSRM-talk wrote: > > Hello all, > > > > Well, after a long hiatus, I've finally had time to cut a new > > release. I've bundled up a bunch of the changes that have been > > submitted over the last couple of years, and tagged 5.23.0, and cleaned > > up the changelog/master branch which had been left dangling in an > > unclear state for a while. Build/publish of the various binaries is > > underway and should be complete soon. Here's what's changed - mostly > > bugfixes, but a few small features as well. > > > > - Changes from 5.22.0 > > - Build: > > - FIXED: pessimistic calls to std::move > > [#5560](https://github.com/Project-OSRM/osrm-backend/pull/5561) > > - Features: > > - ADDED: new API parameter - `snapping=any|default` to allow > > snapping to previously unsnappable edges > > [#5361](https://github.com/Project-OSRM/osrm-backend/pull/5361) > > - ADDED: keepalive support to the osrm-routed HTTP server > > [#5518](https://github.com/Project-OSRM/osrm-backend/pull/5518) > > - ADDED: flatbuffers output format support > > [#5513](https://github.com/Project-OSRM/osrm-backend/pull/5513) > > - ADDED: Global 'skip_waypoints' option > > [#5556](https://github.com/Project-OSRM/osrm-backend/pull/5556) > > - FIXED: Install the libosrm_guidance library correctly > > [#5604](https://github.com/Project-OSRM/osrm-backend/pull/5604) > > - FIXED: Http Handler can now deal witch optional whitespace > > between header-key and -value > > [#5606](https://github.com/Project-OSRM/osrm-backend/issues/5606) > > - Routing: > > - CHANGED: allow routing past `barrier=arch` > > [#5352](https://github.com/Project-OSRM/osrm-backend/pull/5352) > > - CHANGED: default car weight was reduced to 2000 kg. > > [#5371](https://github.com/Project-OSRM/osrm-backend/pull/5371) > > - CHANGED: default car height was reduced to 2 meters. > > [#5389](https://github.com/Project-OSRM/osrm-backend/pull/5389) > > - FIXED: treat `bicycle=use_sidepath` as no access on the tagged > > way. [#5622](https://github.com/Project-OSRM/osrm-backend/pull/5622) > > - FIXED: fix table result when source and destination on same > > one-way segment. > > [#5828](https://github.com/Project-OSRM/osrm-backend/pull/5828) > > - FIXED: fix occasional segfault when swapping data with > > osrm-datastore and using `exclude=` > > [#5844](https://github.com/Project-OSRM/osrm-backend/pull/5844) > > - FIXED: fix crash in MLD alternative search if source or target > > are invalid [#5851]( > https://github.com/Project-OSRM/osrm-backend/pull/5851) > > - Misc: > > - CHANGED: Reduce memory usage for raster source handling. > > [#5572](https://github.com/Project-OSRM/osrm-backend/pull/5572) > > - CHANGED: Add cmake option `ENABLE_DEBUG_LOGGING` to control > > whether output debug logging. > > [#3427](https://github.com/Project-OSRM/osrm-backend/issues/3427) > > - CHANGED: updated extent of Hong Kong as left hand drive > > country. [#5535]( > https://github.com/Project-OSRM/osrm-backend/issues/5535) > > - FIXED: corrected error message when failing to snap input > > coordinates [#5846]( > https://github.com/Project-OSRM/osrm-backend/pull/5846) > > - Infrastructure > > - REMOVED: STXXL support removed as STXXL became abandonware. > > [#5760](https://github.com/Project-OSRM/osrm-backend/pull/5760) > > > > daniel > > > > _______________________________________________ > > OSRM-talk mailing list > > OSRM-talk@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/osrm-talk > > > > _______________________________________________ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk >
_______________________________________________ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
