[zeromq-dev] Moving to 0MQ/3.0, yes or no?

[Martin Sustrik]

On 04/10/2011 09:11 AM, Pieter Hintjens wrote:

> This seems like a false dichotomy.

Well, my point is that backward uncompatible changes are painful for 
everybody, especially those having the code in production and language 
binding authors. Thus we have to have very good justification for 
breaking the backward compatibility.

The justification IMO was:

1. Fix the design flaws.
2. Simplify the codebase by removing tweaks.
3. Make the API more POSIX like.
4. Split unrelated functionality (c++, devices, swap) into separate 
projects to allow them to evolve in more flexible manner.

As for 1. it cannot be done. People are using the tweaks and removing 
them would hurt them.

As for 2. it can't be done. Same reason as 1. This raises issues about 
maintainability of the codebase. With all the tweaks accumulated over 
the years the core the maintenance becomes a task for serious dedicated 
programming team, rather than a single dev working on it in his free 
time in parallel with couple of other projects. I would like to allocate 
some time for discussing this at the conference.

As for 3. it's my personal experiment that I've tried to get into the 
project along with other changes. Presumably, it should be done on 
private branch rather then imposing it no the community.

As for 4., it still remains valid, but I am not sure the point is as 
important as to break backward compatibility. Moreover, some stuff can 
be done in more or less contained and un-obtrusive way (splitting the 
c++ binding).

Martin