[zeromq-dev] ZeroMQ 4.2 release, planning

Brian Knox bknox at digitalocean.com
Tue May 3 21:33:08 CEST 2016


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 <ph at imatix.com> wrote:

> Wow... :)
>
> On Tue, May 3, 2016 at 7:36 PM, Brian Knox <bknox at digitalocean.com> 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.  If these are still considered draft and won't be built by
> default
> > that's fine, I manage our zeromq / czmq packages and have custom ones
> > anyway.
> >
> > Brian
> >
> > On Tue, May 3, 2016 at 8:13 AM Luca Boccassi <luca.boccassi at gmail.com>
> > wrote:
> >>
> >> 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). Yay! So we can now release stable master
> >> > safely, while continuing to refine and extend the draft API sections.
> >>
> >> :-)
> >>
> >> Is any of the API I marked as draft actually ready for release?
> >>
> >> > I propose:
> >> >
> >> > - to end with the stable fork policy; this was needed years ago when
> >> > we had massively unstable masters. It's no longer a problem.
> >>
> >> I like not using forks anymore, as having a separate git history is a
> >> pain for backporting fixes.
> >> So should we use branches instead for bugfix releases?
> >>
> >> > - to use the github release function for libzmq releases and deprecate
> >> > the separate delivery of tarballs.
> >> > - we aim to make a 4.2.0 rc asap, then fix any issues we get, with
> >> > patch releases as usual.
> >> > - we backport the release function to older maintained releases (4.1,
> >> > 3.2) so that their tarballs are provided by github instead of
> >> > downloads.zeromq.org.
> >> >
> >> > Problems:
> >> >
> >> > - this will break a few things that depend on downloads.zeromq.org.
> To
> >> > be fixed as we go.
> >> > - github tarballs are not identical to source tarballs, particularly
> >> > they lack `configure`. I propose changing our autotools build
> >> > instructions so they always start with `./autogen,sh` no matter where
> >> > the sources come from.
> >>
> >> The problem is that will add all the autotools chain as a
> >> build-dependency. And given that the end result varies massively
> >> depending on version and platform, this might create more issues for
> >> users.
> >>
> >> Isn't it possible to do the github release thing with the result of
> >> "make dist"? I think I've read somewhere that you can use the result of
> >> CI builds. If that's the case, we can still use the make dist release
> >> tarballs IMHO.
> >>
> >> Kind regards,
> >> Luca Boccassi
> >> _______________________________________________
> >> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160503/98e891b6/attachment.htm>


More information about the zeromq-dev mailing list