Re: [zeromq-dev] ZeroMQ 4.2 release, planning

Hi, Just for a curiosity - the content of packaging/debian collide with standard Debian packaging? It is intentionally there to not clash, so maybe solve this problem. Either by not generating them, either by defying safer location. On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote: > One

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

On 4/05/16 8:21, Luca Boccassi wrote: But most importantly, the tarball will ship stuff that shouldn't be shipped, which is a huge problem for distribution packagers. To echo this: if there are things in the upstream tarball that they shouldn't ship, they have to undo things from the upstream

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote: > One note, 'make dist' always fails the first few times because files > are missing. Keep this in mind. The git tarball has the great > advantage of never failing. (And since it makes tarballs look like git > clones it gives the same

Re: [zeromq-dev] Malamute Users - Service Requests API

Hi, There is nothing like that in malamute broker as far as I know. You would need to design a custom protocol between client and service to do so. Dne 3. 5. 2016 8:04 PM napsal uživatel "Osiris Pedroso" : > Either that or a heartbeat which would reset the timeout timer. >

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

Wow... :) On Tue, May 3, 2016 at 7:36 PM, Brian Knox wrote: > As a heads up I'm adding support for RADIO / DISH, SCATTER / GATHER and > CLIENT / SERVER to rsyslog for the 8.19 release later this month. The code > will be wrapped with define checks so keep it safe to

Re: [zeromq-dev] Malamute Users - Service Requests API

Either that or a heartbeat which would reset the timeout timer. This would also require an API to confirm that a service request completed with success or failure status. Only then the service request would be removed from requests queue. If timeout is reached, the request would become

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

As a heads up I'm adding support for RADIO / DISH, SCATTER / GATHER and CLIENT / SERVER to rsyslog for the 8.19 release later this month. The code will be wrapped with define checks so keep it safe to compile against CZMQ stable. If these are still considered draft and won't be built by default

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

I'm for not using branches/repository. This is we do it in NetMQ, all fixes on master + releasing from master. Much simpler. On May 3, 2016 19:27, "Pieter Hintjens" wrote: > One note, 'make dist' always fails the first few times because files > are missing. Keep this in mind.

Re: [zeromq-dev] Malamute Users - Service Requests API

Hi, By timeout you mean that client expects an answer for service request in $foo seconds? Dne 2. 5. 2016 1:15 PM napsal uživatel "Osiris Pedroso" : > Hi, > > I am new to Malamute and wanted to exchange words with some other user of > the Service Requests API in Malamute. >

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi wrote: > Is any of the API I marked as draft actually ready for release? Even so, leave it 'draft' until it's actually being used. Changing minds is expensive otherwise. > So should we use branches instead for bugfix

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

On Tue, 2016-05-03 at 13:26 +0200, Kevin Sapper wrote: > I'm currently experimenting with travis automated github releases and > finally gotten to the point where things add up. > > I could try to set this up for libzmq but I need to know how to build the > release tarballs, checksums, changelog,

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

On Tue, 2016-05-03 at 10:39 +0200, Pieter Hintjens wrote: > Hi all, > > I'm just throwing some ideas on the table. We have a good package of > work on master and it's probably time to make a 4.2 release. > > Luca has already back-ported the enable/disable draft design from > zproject (CZMQ et

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

I'm currently experimenting with travis automated github releases and finally gotten to the point where things add up. I could try to set this up for libzmq but I need to know how to build the release tarballs, checksums, changelog, debs, rpms, etc. Then I can make travis upload those artifacts

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

The ztools/zmqapi tool generates the 4.2 docs from libzmq master (see apiall script below). The generation tool checks out specific repos/tags for each release, so you can easily set it to generate 4.2.0 from a tagged release. Relevant piece from apiall: # DirectoryTag

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

Question about the API documentation, now at api.zeromq.org we have docs for each version coming from the stable branches. Should we still have docs for v4.2 separate from master docs? if so where the v4.2 docs are coming from? We can drop the docs per separate versions as we now only have