Re: [OSRM-talk] New v5.23.0 release
> But that change actually breaks the intended change - binary exchange > protocol. Fair point. It breaks the new interface. An alternative could be to offer the old and new interfaces together. That will resolve the breaking change and not introduce a new one. But there would be two ways to return a JSON response, which might be confusing. Michael ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] New v5.23.0 release
Actually i just realized, that i've made a patch for libosrmc a year ago: https://github.com/daniel-j-h/libosrmc/pull/17 I'll ask the libosrmc maintainter to check it one more time. вс, 18 окт. 2020 г. в 19:55, Denis Chapligin : > But that change actually breaks the intended change - binary exchange > protocol. > > вс, 18 окт. 2020 г. в 08:37, Michael Bell : > >> 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 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 < >> 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 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
Re: [OSRM-talk] New v5.23.0 release
But that change actually breaks the intended change - binary exchange protocol. вс, 18 окт. 2020 г. в 08:37, Michael Bell : > 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 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 < > 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 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. > >>> >
Re: [OSRM-talk] New v5.23.0 release
Thanks a lot Daniel, Denis and Michael for your answers. Michael, I did not go through the details of your changes in PR #5860, but I gave a go at building and installing. I can confirm that the dowstream compilation problem reported in #5741 is gone with your changes. Regards Julien On 18/10/2020 07:34, Michael Bell wrote: 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 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 : 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 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
Re: [OSRM-talk] New v5.23.0 release
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 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 > : >> >> 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 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. >>> >
Re: [OSRM-talk] New v5.23.0 release
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 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
Re: [OSRM-talk] New v5.23.0 release
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 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. > >
[OSRM-talk] New v5.23.0 release
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
