No new official release since 2016
Snyk can only track official releases. The latest official release is more than 8 years. What's the official release process here for this repo? Can we request an official release with a specific commit, e.g. fd3dc29a5c2852df569e1ea81dbde2c412ac5051
Why are there 100 pull-requests and over 600 open issues and so few recent commits with a company like Tencent behind it?
yeah, this needs some attention. there are deprecation issues with c++20.
See https://github.com/Tencent/rapidjson/issues/2284
Version 1.1.0 doesn't work with GCC 14 or Clang 19. The problem was solved 1 day after the release (3b2441b), but the Debian package still has it. And other packages (like mlpack) depend on it. This is so frustrating.
I can just repeat what everyone says in persistent loops. Most Linux distros pick up versions of software packages from GitHub by looking at their release tag. Not setting a new release tag renders any development of RapidJSON useless for most Linux distros.
Yeah, it would really helpful to get a release. @miloyip I saw you merged some changes recently. Could help with this?
Looking forward to a new release. pls.
Since we've had no response from them, I've personally switched to https://github.com/nlohmann/json since it has a modern API that doesn't have a problem with C++20/24 and has more recent releases (along with other nice features)
Maybe we should think about making an official fork - sth like RapidJSON-ng. Does anyone feel called?
I won't have much time contributing to the fork (if there will be one), but happy to package it for a few distros I am using.
Since we've had no response from them, I've personally switched to https://github.com/nlohmann/json since it has a modern API that doesn't have a problem with C++20/24 and has more recent releases (along with other nice features)
Nlohmann JSON is great, but funnily enough I migrated away from it because it's not designed for great performance, it's acceptable but it does too many allocations under the hood, it's designed to be simple and very object orientated, not fast and efficient. It's too bad simdjson doesn't support writing JSON (I believe they're open to it but lack the maintainers, planning time, etc), otherwise I'd completely move away from rapidjson instead of using it alongside simdjson.
Besides, rapidjson is still sort of maintained, I see a few commits here now and then with fixes to bugs, so it's safe to assume the master branch is the "release", I have no idea why they're not packaging these commits into releases anymore though. I think a fork that simply packages commits into releases would work wonders.