But that change actually breaks the intended change - binary exchange protocol.
вс, 18 окт. 2020 г. в 08:37, Michael Bell <[email protected]>: > I've had a go at reverting the breaking change: > https://github.com/Project-OSRM/osrm-backend/pull/5860 > I was able to compile libosrmc against it. > > Michael > > On Thu, 15 Oct 2020 at 17:14, Denis Chapligin <[email protected]> wrote: > > > > 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 < > [email protected]>: > >> > >> 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 <[email protected]> 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 > >>> > [email protected] > >>> > https://lists.openstreetmap.org/listinfo/osrm-talk > >>> > > >>> > >>> _______________________________________________ > >>> OSRM-talk mailing list > >>> [email protected] > >>> https://lists.openstreetmap.org/listinfo/osrm-talk > >> > >> _______________________________________________ > >> OSRM-talk mailing list > >> [email protected] > >> https://lists.openstreetmap.org/listinfo/osrm-talk > > > > _______________________________________________ > > OSRM-talk mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/osrm-talk > > _______________________________________________ > OSRM-talk mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk >
_______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
