Wow... :)
On Tue, May 3, 2016 at 7:36 PM, Brian Knox <bk...@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.bocca...@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@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
