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 <akash...@gmail.com> 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 <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
_______________________________________________
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
