IIRC you had some idea of hiding that change and unbreaking the API by templating ResultT type. If you can explain your idea I can probably implement it.
чт, 15 окт. 2020 г. в 17:43, Daniel Patterson via OSRM-talk < osrm-talk@openstreetmap.org>: > 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 >
_______________________________________________ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk