search

zeromq / cppzmq

Header-only C++ binding for libzmq
http://www.zeromq.org
MIT License
1.95k stars 757 forks source link

Bold plan for a major release #400

Open gummif opened 4 years ago

gummif commented 4 years ago

Here are a few ideas for changes to be made for (potentially breaking) cppzmq v5.

  1. Require C++11 standard support, but still support gcc 4.7 and later with partial C++11 support. This possible future requirement has been in the read me for 2 years now. Large fraction of the library now requires C++11.
  2. Require libzmq 4.0+. There are no CI tests with older versions and there are no releases on github for version prior to 4.0.6. (should we maybe require 4.1 or 4.2?)
  3. Remove deprecated functions that would not cause silent breakage (would cause compile time errors). Keep functions that would cause silent changes to runtime behavior if removed (e.g. greedy function overloads).

These changes are conservative in the sense that if you are using C++11 or later, libzmq v4 or later and not using any deprecated functionality, then the upgrade from the latest v4 to v5 should not require any changes to you code. If you do use deprecated functions then you might get a compile time error in the worst case.

bluca commented 4 years ago

Please do not break backward compatibility. This header is shipped in distributions. It would cause major, major headaches and work to downstreams.

gummif commented 4 years ago

After some deep though I can see that part 3 and maybe part 2 could cause some pain with system packages (system packages are generally a bad idea anyway for development). I don't know how the process is for adding new package versions to distributions, but I guess it is their responsibility to not add package versions that would break the system? But if it is possible people will eventually managed to break things.

About requiring C++11, the read me says "Some features already require a compiler supporting C++11. In the future, probably all features will require C++11". Is that something that you prefer never happens?

And regarding part2, I believe libzmq v3.x is rarely used. And it would be very unlikely that someone would use libzmq v3.x together with latest cppzmq, so in practice that would requirement should have no effect (in that event an option would be to simply update libzmq or not update cppzmq). Correct me if you can come up with a situation where that would be the case.

bluca commented 4 years ago

I don't know how the process is for adding new package versions to distributions, but I guess it is their responsibility to not add package versions that would break the system?

Yes, but it means there will never be a new version uploaded, which is not good.

The problem is not C++11 so much for distros - they all support it, it's just the ancient and deprecated stuff that doesn't. Not even zmq 3.x. The problem is breaking API compatibility by removing functions.

gummif commented 4 years ago

OK. So would you see the following would be acceptable?

  1. Require C++11 standard support, but still support gcc 4.7 and later with partial C++11 support.
  2. Require libzmq 4.0+.
  3. Make bug fix releases for v4 if required for C++03 compatible code.
bluca commented 4 years ago

That would be fine, yes

planetmarshall commented 3 years ago

Here are a few ideas for changes to be made for (potentially breaking) cppzmq v5.

  1. Require C++11 standard support, but still support gcc 4.7 and later with partial C++11 support. This possible future requirement has been in the read me for 2 years now. Large fraction of the library now requires C++11.

Skip C++11, C++14 and C++17, move to C++20 and provide an asynchronous API based on coroutines, mirroring asyncio support in the PyZMQ library.

gummif commented 3 years ago

I think coroutine support could be added as an addon for those that have compilers that support it. I have been thinking about it but have not yet thought of a good solution (adding an async API on top of a blocking API is not ideal).