search

USCiLab / cereal

A C++11 library for serialization
BSD 3-Clause "New" or "Revised" License
4.24k stars 764 forks source link

Next release date #563

Closed crazyhappygame closed 5 years ago

crazyhappygame commented 5 years ago

When we may expect the next release?

AzothAmmo commented 5 years ago

I can't give a definite date but the good news is that I've actually started to develop a little for cereal again. If things go well I'd say within a few weeks.

I plan to make develop the default branch and get rid of the concept of a dual master/develop branch. I'll also work on closing up and releasing the oldest milestone, potentially dropping some things I had slated for it just to get some of the fixes in develop out.

crazyhappygame commented 5 years ago

Thank you! Great news. About branches:

  1. Why not just 1 branch master?
  2. How should I create pull request for next release to develop or to master?
h-2 commented 5 years ago

I can't give a definite date but the good news is that I've actually started to develop a little for cereal again. If things go well I'd say within a few weeks.

That's great to hear! Is there any chance you could look into the following or would accept PRs that deal with:

AzothAmmo commented 5 years ago

@crazyhappygame It'll probably just be the master branch - either way there will be one mainline branch that is always up-to-date and then tagged releases once in a while.

For now please keep making pull requests against the develop branch until I consolidate them. My focus right now is on getting the CI working properly once again and then fixing issues with that.

@h-2 I'll look into those - your static_assert I think I'm fine with accepting - I'm going to admit defeat on making that one work properly and this will be the better solution for now.

I'll consider the git submodule idea as well - I still want to maintain an easy way to bundle everything together for those that don't want to deal with providing a system install of rapid json or xml.

h-2 commented 5 years ago

Great, thanks for working on cereal again :+1:

I'll consider the git submodule idea as well - I still want to maintain an easy way to bundle everything together for those that don't want to deal with providing a system install of rapid json or xml.

Sure! It's quite easy with submodules, actually, people can just call git clone --recursive and will get the submodules automatically. But you could also offer an extra tar/zip-ball of course... In any case it will make people stop complaining about warnings in those files, because you can redirect them to the upstream repository :wink:

That having been said, if you are willing to drop GCC < 5, you can very easily make dependencies optional via the __has_include-macro, i.e. the text archives could be entirely optional, by inserting a few lines at the beginning of the respective header:

#if !__has_include(<rapidjson/rapidjson.h>)
#error You have included the JSON Text archive, but this is only available with RapidJSON.
#else

// rest of file

#endif

For header-only libraries this works really well for us and it would mean that people only interested in binary archives don't even need those submodules.

h-2 commented 5 years ago

Any news here? Thank you!

h-2 commented 5 years ago

I can submit a PR for the submodule thing if you want to! Even without the submodule thing it would be crucial for us to have a release that includes #565, otherwise we cannot ship a stable release of our library.

h-2 commented 5 years ago

Thank you for writing this incredibly useful library, but I have to say that using it is increasingly frustrating and there are more and more forks.

Can you please do one of the following:

  1. State a time frame in which you will review open PRs, answer to serious issues and publish an updated release.
  2. Give other people like me and/or @uentity (I am not related with them in any way) write access to this repository, so we can do it.
  3. Close the issue tracker and the PR tracker and clearly state in the documentation that this project is abandoned, so we can establish a different fork and users can move on.

Thank you.

uentity commented 5 years ago

Hi everybody

First of all, I'm glad to hear that development is going on.

Next, I don't think that I need a write access to this repo, because high possibilities = high responsibility that I'm not ready to in this project )

Finally, I don't expect that most of features stated in #578 will be accepted upstream for reasons I already stated there. At the same time, most changes I've made (including tweaks in Cereal internals) are absolutely harmless and invisible from client code, but allows for greater possibilities. Maybe @Azothammo will find and implement better ways to do what I did. For example, out-of-order shared ptrs deserialization and merging serialization code across multiple DLLs are essential and very useful for my projects.

breznak commented 5 years ago

It has been 2 years since the latest stable v1.2.2 release, it would be nice if you could just wrap up the current develop branch, test it, and merge it to master + tagging a new release. The goodies have accumulated and I'd be happy to use the news as is in develop.

Btw, :+1: to avoiding the master/develop branches, just have master and use tags for stable& tested release points.

AzothAmmo commented 5 years ago

Hi all - just a quick reply to this - I was trying to fix all of the tests before releasing but will forgo that just to keep things moving. There are some warnings related to rapidjson that will not be fixed yet. Will do my best to get this out when back from vacation in two weeks.

On Thu, Oct 3, 2019, 11:19 AM breznak notifications@github.com wrote:

It has been 2 years since the latest stable v1.2.2 release, it would be nice if you could just wrap up the current develop branch, test it, and merge it to master + tagging a new release. The goodies have accumulated and I'd be happy to use the news as is in develop.

Btw, 👍 to avoiding the master/develop branches, just have master and use tags for stable& tested release points.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/USCiLab/cereal/issues/563?email_source=notifications&email_token=AAMPCT5SFFG4MORPEYE462TQMYZRTA5CNFSM4HJTC5CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJDPGY#issuecomment-538064795, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMPCTY7CFNCH4XHDUPQN4DQMYZRTANCNFSM4HJTC5CA .

AzothAmmo commented 5 years ago

Should have the next release out this week - it will release with a few configurations of unit tests not passing. I'm also going to try and drop the develop branches in favor of only using the main branches + forks for development.

h-2 commented 5 years ago

Thanks a lot for working on this again! Any chance #565 will make it in? It's a blocker for us and you already said above that you would be willing to accept it :pray:

Devacor commented 5 years ago

Can you take a quick look at this fix as well? No associated pull request, but inline code in the thread:

https://github.com/USCiLab/cereal/issues/523

SnapperTT commented 5 years ago

Hi Azoth, its great to see your still maintaing this project. Any chance that we going to see optional fields for loading via JSON (eg: https://github.com/USCiLab/cereal/issues/30#issuecomment-26779545 ) ?

breznak commented 5 years ago

I understand everyone would now come up with a need they would love to see fixed/merged. Taking the developer's time in question, I really think the correct thing would be to call a freeze, release ASAP as-is, and then the PRs can be updated and taken one by one, merged to master, as in agile development. Noone says next release cannot be a (few) week after this one.

Have a great weekend and looking forward :100:

AzothAmmo commented 5 years ago

I've got nearly everything that was slated for the 1.2.3 milestone ready to go. Trying to clean up some rough edges from merging #509 - I may have to revert that and push it to a future release if it continues to hold things up. Documentation is almost all done too.

Most environments should pass all of their tests - there will be a few that do not though. This seems partially due to updating doctest (require some work to accommodate older compilers) as well as the most recent rapidjson still not being good enough for modern warnings.

It'd be pretty great to start dropping support for early C++11 compilers, but I unfortunately have no insight into the platforms people are using cereal on.

AzothAmmo commented 5 years ago

PS: Will also merge #565 with a slight modification (just going to comment out the code with some comments for the future). Currently have every MSVC test passing, and the majority of the others.

h-2 commented 5 years ago

Thank you very much! I would still volunteer to create a PR that modularises cereal (making rapid* optional and autodetected), but that can wait for after the release!

It'd be pretty great to start dropping support for early C++11 compilers, but I unfortunately have no insight into the platforms people are using cereal on.

FYI, we don't require anything older than GCC7, but I imagine just dropping GCC < 5 would already help significantly as the late GCC4.x were really buggy.

AzothAmmo commented 5 years ago

Will probably be able to finalize the release tomorrow. I finished up most things that had the 1.2.3 milestone tag and got all of the tests to pass. Documentation is done as well,

Devacor commented 5 years ago

I just want to say how excited I am to see such a flurry of activity on this project. Thank you @AzothAmmo !

crazyhappygame commented 5 years ago

Thank you