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

[Brian Granger]

Martin (and others),

> In the recent month, the discussion about 0MQ/3.0 have shown that the
> radical "parting with the past design flaws" goal of the endeavour
> cannot be achieved. Every tweak has its user that will be hurt if its
> removed. That makes the 3.0 version more or less useless: The flaws
> won't be fixed while at the same time the backward incompatible changes
> will hurt everybody.

I am sorry if I have contributed to you concluding that we should not
break backwards compat or attempt major things for 3.0.  I wanted to
clarify this ...

* Breaking backwards compat to fix past design flaws is absolutely
important and 3.0 provides a good place to pursue these things.
* These things should be handled with an incremental approach.  Flaws
should be tackled one by one with community discussion.
* I don't think that "removing functionality" (PAIR sockets,
zmq_device) should be considered unless we are absolutely sure that no
one is using it or it is fundamentally broken.  If the current
implementations have problems that required API changes to fix, then
lets pursue that.  But merely removing things that users are actually
using will only make people mad.

...and provide some perspective...

* The 2.0 API has been wildly successful!  With it, we have been able
to build insanely complex distributed applications that perform
10-100X better than our previous versions with much less code and much
more functionality.  We have looked at lots of different
network/messaging layer libraries and nothing even come close to
zeromq.  Please don't loose sight of this.
* As a sign of the success of the project, the community has grown
massively in the last year.
* When building complex zeromq applications, there is *very little* we
find to complain about.
* From the packaging, build, community perspective, we like having all
the core zeromq code in one repo.
* I guarantee that the range of applications that zeromq users are
building *far* exceeds our wildest imaginations.  Think of giving
people LEGO blocks.  They are going to go out and do amazing things.
Because many of these things are commercial in nature, we are never
going to hear about them.  But that doesn't mean they are not out
there.  I know of zeromq being used by a major company.  A person
close to that work has described it as "mind blowing".

> Thus, we should revert the 3.0-related changes on master and go further
> with 2.x version, in a fully backward compatible way.

I think there is a 3rd option.  What about establishing a more formal
approach for the 3.0 changes that will break backwards compatibility:

* github issues now has milestone support.  Let have people open
issues for each of the proposed changes and target them to a 3.0
milestone.  These issues could be used to track the
discussion/progress on each of them.  We could also use the wiki for
this purpose, but github issues can link to pull requests, branches
etc and git hub keeps them around, which is a nice reference.
* Leave existing changes in the 3.0 branch, but still open up issues
for them to track the discussion.  If the discussion of a particular
change concludes that the change should be backed out, then that can
be done.  Obviously other conclusions, like leaving it in as is or
making further changes could also happen.
* For things that are hotly debated, polling the community "owners"
probably makes sense.

Cheers,

Brian

> Thoughts anyone?
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com