[zeromq-dev] ZeroMQ 4.2 release, planning

Pieter Hintjens ph at imatix.com
Tue May 3 20:07:45 CEST 2016


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



More information about the zeromq-dev mailing list