Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abandoned? #842

Open
rjzak opened this issue Nov 16, 2024 · 13 comments
Open

Abandoned? #842

rjzak opened this issue Nov 16, 2024 · 13 comments

Comments

@rjzak
Copy link

rjzak commented Nov 16, 2024

Since there hasn't been any activity with the code base in almost a year, is this project abandoned?

This question was also asked on the mailing list without response. https://groups.google.com/g/cerealcpp/c/PW1NHZdFUKU/m/jvnMwlI0AwAJ

@AzothAmmo
Copy link
Contributor

cereal has not been abandoned, maybe neglected is a better word? Our CI pipeline has been broken for a while and I haven't taken the time to fix it (nor has anyone else), which is making it difficult to merge pull requests. cereal supports a wide range of compilers and systems right now and ensuring that we don't break anything is fairly important.

I have been tempted to drop support for some older compilers - we don't have any usage statistics but I have to imagine that the number of users on something like GCC < 5 or MSVC13 is quite low now.

@lordvictory
Copy link

This library is an amazing piece of work.

I actively use this serialization library. IMHO, it's the best and easiest to work with. I usually use it in embedded systems for custom RPC, by creating a templated class that encodes/decodes all messages sent and received using the included portable binary format. On a 1Ghz iMX8 w/gigabit ethernet it takes approx. 1 millisecond round trip between 2 systems for a single request/response cycle.

In regards to compiler support, I'd certainly drop any compiler version that didn't have full C++11 support (including full C++11 library support). In my experience, full library support oftens lags by several versions from when they say the compiler may support it, particularly for some embedded systems.

In my current project, using newer compilers presents some issues in regards to many warnings, mostly due to language changes between C++11 and C++20 with g++ v13.2.

Would be nice to see the library updated a bit for better compatibility with the newer language standards.

@sjrdc
Copy link
Contributor

sjrdc commented Dec 3, 2024

@AzothAmmo so are there any plans on how to take this project forward? I think it is a really great project that has a lot of practical value and usage, and it would be a pity to let it slip into further neglected and then abandoned state.

Can we discuss what is needed to get it going again?

@sjrdc
Copy link
Contributor

sjrdc commented Dec 9, 2024

I am fixing linux CI with #846; let's meanwhile try to come up with some directions, for example

  • create an organization to take this project forward and establish a broader governance structure for it
  • decide on a fork and take the fork further

@AzothAmmo
Copy link
Contributor

I'll be able to review your MR next week.

@TheOnlyJoey
Copy link

Also any way to contribute to the project financially for those with limited time who still want to contribute?
Thanks ^_^

@AzothAmmo
Copy link
Contributor

I've merged the linux CI fixes - will still need to address the osx / windows stuff but this is good progress for getting into a more normal cadence of reviewing MRs.

@sjrdc
Copy link
Contributor

sjrdc commented Dec 22, 2024

For macOS, the solution can be as easy as adopting the compilers available in the latest macOS docker image. Is that an acceptable direction? What is the significance of testing the current old xcode versions?

@AzothAmmo
Copy link
Contributor

The versions in there are simply those that were current when the tests were written, more or less. I'm not really familiar with macOS development so I don't know which versions still make sense to target.

@rjzak
Copy link
Author

rjzak commented Dec 22, 2024

Maybe just test on current and current - 1?

@sjrdc
Copy link
Contributor

sjrdc commented Dec 23, 2024

The versions in there are simply those that were current when the tests were written, more or less. I'm not really familiar with macOS development so I don't know which versions still make sense to target.

Good, let's adopt the same going forward then

@lordvictory
Copy link

Sorry hadn't replied...was on vacation.

I use OSX systems for my general workstation, which I use for all my C++ development. But I don't normally do MacOS development, I usually work on Linux systems these days.

Having said that, I do have the MacOS Command Line Devkit installed, so it shouldn't be much of a chore to attempt command line builds for MacOS. I usually use CMake for building, but I'm not a real maven with it, and try to mostly keep things simple to get the job done.

Just let me know exactly what you'd like done on OSX. I'm currently running Sonoma 14.5.

One of the things I'd like to see done, and perhaps participate in, would be some updating of the routines that do the I/O. C++20 has a number of features that might be utilized for better performance, like std::span<> or std::format_to(). There are more options that are faster and more generic in C++20.

@madscientist42
Copy link

C++20 might be a bit of a bridge too far unless you can option for both something like 11 and then 20 as a gearshift. I mean, it is already fast to begin with. ;)

Good to see life here. About to add a Yocto recipe for things here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants