Hi Julien,

The 'unstable' version of 0MQ is simply a less fully tested version;
it builds properly, we have build engines that check that on various
platforms, and bug patches are applied very rapidly. The usual advice
for a project is to use the master HEAD while you're developing your
architecture, and then track that branch as it becomes a formal
release, and then a stable release (since you generally want new apps
to be using new infrastructure, and old apps to use old
infrastructure). Bug fixes get backported into stable in any case
unless there is a strong reason not to do so. By using the master head
you also contribute to testing that and making it more robust for
everyone else.

-
Pieter Hintjens
iMatix

On Sun, Feb 13, 2011 at 6:24 PM, Schmurfy <[email protected]> wrote:
> Thanks for the clarifications, I have nothing against helping :)
> I will try backporting it to maint, I noticed weird behaviors working with
> 2.1 and head but I cannot pinpoint if it is a bug or if I did something
> wrong.
> About the master branch, by what you said I suppose it is considered to be
> working ? I mean that half coded things will live in a separate branch
> before being merge to master.
> The reason for the question is that I already saw projects where head was
> not compiling half of the time and that is really annoying working that way.
> Julien Ammous
>
> On 13 February 2011 17:21, Martin Sustrik <[email protected]> wrote:
>>
>> Hi Julien,
>>
>>> I wanted to know if there is any estimate as to when we can hope to see
>>> ZMQ_EVENTS / ZMQ_FD support in a stable release
>>
>> It depends on how much testing is done by various parties. If you want to
>> speed it up simply start using the 2.1 and report any bugs you may
>> encounter.
>>
>>> I honestly don't
>>> understand clearly how the releases are done and when (and I never
>>> understood the need for an "unstable "release ;) ).
>>
>> To have a common reference point, something you can report issues about
>> etc.
>>
>>> I really love zeromq, it is a really nice library and want to try it on
>>> a work project but I want to integrates it with an event loop which is
>>> why I need these two features, I already got working code for the most
>>> part but working on an unstable or on HEAD is not really an option so
>>> here I comes.
>>
>> Then you'll have to wait. That's the nature of collaborative development.
>> You'll either help with what you want to see in the product or you just wait
>> till others do it for you.
>>
>>> My concern is that it looks like a lot of things is happening on the
>>> master branch with XPUB, XSUB and other things so my question is: are
>>> all these features going to be released at once or will they be cut in
>>> parts and released by pieces in stable versions ?
>>
>> XPUB and XSUB were added to the master to indicate that there will be such
>> functionality in the future, however, all the non-trivial work on
>> subscription forwarding is done outside of master, on sub-forward branch.
>>
>>> It would be great to have a minor release adding EVENTS/FD to be able to
>>> start to really use the library with an event loop efficiently.
>>
>> If you want to backport EVENTS/FD to the maint branch, feel free to do so.
>> Provide the patch in the standard way, just note it's a patch to maint
>> instead of master:
>>
>> http://www.zeromq.org/docs:contributing
>>
>> Martin
>
>
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to