[zeromq-dev] Making language bindings work with both maint andmaster

Daisuke Maki lestrrat at gmail.com
Mon Oct 4 08:29:48 CEST 2010


I'm not sure why "master" and "maint" are featured here -- are we talking
about the scenario where version X was released, but before version X + 1 is
released and master still has the version number X ?

If the above is correct, why don't zmq simply up the internal version number
to X + 1 upon the release of X ?

Oh wait, or are you saying that currently there's no way to figure out the
version of zmq before compiling the bindings?
If that's the case I'd rather have a command line utility "zmq-config",
rather than a typedef so I can detect it even before I start compiling
my binding.
(Yes, I know we've already had this discussion elsewhere)

As for using the same baseline for bindings and the libzmq version, I'm very
against it. Maintaining binding modules on CPAN has often showed that this
causes more pain to the users (not the maintainers) .... unless we're actually
bundling the bindings with the main library (which I'm also against, because
that's just not how Perl works)

I think each language would have a preferred way to maintain such bindings,
and to tie the main library and the bindings like that may work for
one language,
but would cause severe pain for others. I'd vote for a much looser coupling
of between the main library and the bindings, such as via #define ZMQ_VERSION or
an external script like zmq-config I proposed above.

--d

2010/10/3 Martin Sustrik <sustrik at 250bpm.com>:
> Joshua,
>
> That may actually work.
>
> Thoughts anyone?
>
> Martin
>
> On 10/03/2010 03:12 AM, Joshua Foster wrote:
>>    Another approach is to tag the binding's baseline with the version
>> that it matches. That way if we want to use 2.0.8, we just update to
>> that tag. If there is a version specific fix, we can always create a
>> small branch for that version.
>>
>> Joshua
>>
>> On 10/2/2010 4:34 PM, Mikko Koppanen wrote:
>>> On Sat, Oct 2, 2010 at 9:01 PM, Martin Sustrik<sustrik at 250bpm.com>   wrote:
>>>> On 10/02/2010 09:59 PM, gonzalo diethelm wrote:
>>>>> My suggestion was to have #define macros to identify the version of 0MQ
>>>>> against which a binding is being compiled. Something like ZMQ_MAJOR,
>>>>> ZMQ_MINOR, etc. Or a single #define ZMQ_VERSION to 20101002 (YYYYMMDD).
>>>> Yeah, something like that. Let's see what other binding maintainer say
>>>> about the topic.
>>> Hi,
>>>
>>> Things such as ZMQ_TYPE are easy to ifdef out based on the constant
>>> but breaks in functionality or API are possibly harder without
>>> 'pre-processor-checkable' version number.
>>>
>>> Let's say I wanted certain functionality to be present if libzmq
>>> version is 2.1.1 or higher.
>>>
>>> With version id it would be the following (major,three digits for
>>> minor,three digits for patch)
>>>
>>> #if ZMQ_VERSION_ID>= 2001001
>>>
>>> Where as with ZMQ_MAJOR/MINOR/PATCH it would be:
>>>
>>> #if ZMQ_MAJOR>   2 || (ZMQ_MAJOR == 2&&   ZMQ_MINOR>= 1&&   ZMQ_PATCH>= 1)
>>>
>>> I guess this is a matter of taste but I prefer the former one (there
>>> is no harm in defining both).
>>>
>>>
>>> What would be the benefit of using YYYYMMDD instead of the actual
>>> version number?
>>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list