Source: nlohmann-json Version: 2.1.1-1.1 Severity: wishlist I see that upstream is up to version 3.1.2. Is there any reason not to update this package? Is backwards-compatibility known to be good? Forward-compatibility?
I have a package (horizon-eda) which currently uses an internal copy of 3.1.0. It would be good to switch to a packaged library. I see that there are quite a few packages in the archive containing internal copies: pbbam (2015,used) tools/pbindexdump/src/json.hpp pbcopper (2.0.0,used) pbcopper/json/internal/json.hpp fplll (2.0.3,used) fplll/io/json.hpp horizon-eda (3.1.2,used) 3rd_party/nlohmann/json.hpp (multiple files) measurement-kit (2.1.1,used) include/measurement_ket/ext/json.hpp newsboat (3.1.2, used) 3rd-party/json.hpp planetblupi (2.0.0,used) include/pbcopper/json/internal/json.hpp sirikali (2.1.1,used) src/3rdParty/json/nlohmann/json.hpp snapcast (3.1.0,used) common/json.hpp webkit2gtk (2.1.1, used) Source/WebKit/NetworkProcess/capture/json.hpp zulucrypt (2.1.1,used) external_libraries/json/nlohmann/json.hpp (tries standard path first, so just a build-dep may fix) These two include a copy but take steps to use the system version: mkvtoolnix (2.0.0,notused) lib/nlohmann-json/src/json.hpp poedit (2.1.0,notused) src/json/src/json.hpp I've not yet tested compatibility of all these with either the current or the latest version, or whether any are carrying local changes. Currently it looks like the 4 of those using 2.1.1 should 'just work'. The 2 2.0.x using version probably work fine too. Then there's 3 using 3.1.x. I'll test horizon with the existing 2.1.1-1.1 if that works, then I guess they all have a good chance. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)