Repository navigation
No new official release since 2016 #2321
Description
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. fd3dc29
Reacted by Alexander Deynichenko, Florian Richter, Aitor Miguel Blanco, Magnus Håkansson, Kolja, Pavel V. Sysolyatin, Sabbir Ahamed Shubho, Nerixyz, sallyx, Mr Conter and 29 more
Activity
wertzuz commentedon Dec 30, 2024
Why are there 100 pull-requests and over 600 open issues and so few recent commits with a company like Tencent behind it?
digiexchris commentedon Feb 24, 2025
yeah, this needs some attention. there are deprecation issues with c++20.
ks1322 commentedon Feb 27, 2025
See #2284
yehudamber commentedon Mar 11, 2025
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.
rexkogitans commentedon Mar 19, 2025
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.
jlskuz commentedon Apr 2, 2025
Yeah, it would really helpful to get a release. @miloyip I saw you merged some changes recently. Could help with this?
xtexx commentedon Apr 4, 2025
Looking forward to a new release. pls.
digiexchris commentedon Apr 4, 2025
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)
flubshi commentedon Apr 9, 2025
Maybe we should think about making an official fork - sth like RapidJSON-ng.
Does anyone feel called?
xtexx commentedon Apr 11, 2025
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.
SpeedyCraftah commentedon Apr 12, 2025
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.
gvollant commentedon Mar 30, 2026
see #2202 #1919 #1006 #1130 #1341 #1896 #1911 #1881 #1862 #1820 #1130 #1341 #1896 #1911 #1774 #1998 #1976 #2108 #2238 #2266 #2284 #2321
d3matt commentedon Mar 30, 2026
Probably not a bad idea to mark some of those as duplicates?
wertzuz commentedon Mar 31, 2026
No one ist moderating the github that's the issue.
devkaiwang commentedon Apr 20, 2026
Let's abandon this lib.
dbear496 commentedon Sep 27, 2026
Trying to pull in this library with CMake is problematic because master has a very different CMake interface compared to 1.1.0, but since the version numbers are the same, there no good way to make a distinction between the two.
At the very least, it would be nice if the
LIB_VERSION_STRINGCMake variable could be set to1.1.1so CMake projects can distinguish between 1.1.0 and master.devkaiwang commentedon Oct 19, 2026
I have migrate my project to yyjson.