[zeromq-dev] [ANNOUNCE] ZeroMQ/2.2.0 stable released

[Chuck Remes]

On Apr 4, 2012, at 10:44 AM, Brian Granger wrote:

> On Wed, Apr 4, 2012 at 7:21 AM, Santy, Michael
> <Michael.Santy at dynetics.com> wrote:
>>> In theory bindings aim to work with all released versions of 0MQ,
>>> though it's up to each binding group to make this work.
>> 
>> I've been meaning to bring up this topic for a while.  It seems to me that knowing that a specific set of bindings are designed to work with a specific version of 0MQ is a bit confusing for a newcomer (and even someone who follows the mailing list like myself).  Another project that has a similar problem (at a much larger scale) is Eclipse.  In Eclipse there are several related projects that are released as a group (e.g., Indigo, which is the 3.7.x series) and known to work together.  Has there been any discussion in the 0MQ community of bringing in some of the more popular and API stable language bindings (e.g., C++, Java, Python perhaps) into the core distribution that are released as part of 0MQ?  I recall a while back that the C++ bindings went the opposite direction in that they were split from the core 0MQ distribution into their own project, but I never really understood the reasoning.
> 
> I am definitely -1 on this.  It doesn't make sense to tie the release
> cycles, review policies, licenses, etc together like this.

I agree that tying them all together is probably a bad idea. The API doesn't change so rapidly that this kind of bundling is necessary.

The bindings *should* print a warning if they load a version of the library that is either too old or too new. At the minimum this message would clue in the users that they should seek out an update or post an issue asking for an update.

cr