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 al). Yay! So we can now release stable master
safely, while continuing to r
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 master
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
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 to
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 al)
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,
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 releases?
All fixes to master.
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 experience to all developers.)
I'd vote for killing 'make dist'. It als
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.
>
> Malamute being a mes
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. The git tarball has
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
t
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 active/v
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 compile against CZMQ
> stable
Pieter - successfully sent syslog traffic over udp multicast via zeromq
this week, using RADIO / DISH ;)
On Tue, May 3, 2016 at 2:08 PM Pieter Hintjens wrote:
> 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 / GATHE
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.
>
> This would also requ
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 experi
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
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 n
18 matches
Mail list logo