[zeromq-dev] ZeroMQ 4.2 release, planning

Sat Nov 5 10:02:35 CET 2016

Hi,

I will update the website later tonight or tomorrow, I've been
travelling so it's a bit hectic :-)

Yes we discussed this a while ago, and thanks to the DRAFT APIs
mechanism we can now stay on the same repository. Any unstable API will
simply not be available unless enabled at build time. This way we get
all the bug fixes without having to backport and when a new API is ready
we mark it stable and enable it.

On Sat, 2016-11-05 at 09:42 +0100, Michal Vyskocil wrote:
> Hi,
> 
> great work!
> 
> I noticed the zeromq.org download page
> http://zeromq.org/intro:get-the-software hasn't been updated yet.
> 
> I also found out that the 4.2.0 release was tagged in libzmq
> repository instead of zeromq4-2 fork. Does it means that zeromq
> project is moving away from fork model for releases? Or it's just for
> a zero release?
> 
> Bye
> Michal
> 
> On Sat, Nov 5, 2016 at 8:44 AM, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> > Final status update:
> >
> > CZMQ 4.0.0 is out, announcement has been sent:
> >
> > https://github.com/zeromq/czmq/releases/tag/v4.0.0
> >
> > What a ride :-)
> >
> > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the
> > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow.
> >
> > On Fri, 2016-11-04 at 13:35 +0000, Luca Boccassi wrote:
> >> Status update:
> >>
> >> CZMQ release notes PR is open:
> >>
> >> https://github.com/zeromq/czmq/pull/1542
> >>
> >> I will be travelling now until the evening (might have some time at
> >> airport), so if you have anything to add please merge and send a new
> >> PR :-)
> >> I would like to release v4.0.0 tonight, so that I can (barely!) make it
> >> for Debian 9 transition freeze. Phew!
> >>
> >> On Fri, 2016-11-04 at 10:46 +0000, Luca Boccassi wrote:
> >> > Status update:
> >> >
> >> > libzmq 4.2.0 is out! Email sent to the announce list.
> >> >
> >> > https://github.com/zeromq/libzmq/releases/tag/v4.2.0
> >> >
> >> > CZMQ is next!
> >> >
> >> > On Fri, 2016-11-04 at 09:52 +0000, Luca Boccassi wrote:
> >> > > Status update:
> >> > >
> >> > > Added missing CTX option to CZMQ, retired more deprecated methods that
> >> > > are in STABLE classes.
> >> > >
> >> > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still
> >> > > waiting for someone to merge:
> >> > >
> >> > > https://github.com/zeromq/libzmq/pull/2189
> >> > >
> >> > >
> >> > > On 3 November 2016 at 09:34, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> >> > > > Status update:
> >> > > >
> >> > > > I've added all the missing options to CZMQ (check please!), and I prepared
> >> > > > the release notes for libzmq 4.2, waiting for a merge:
> >> > > >
> >> > > > https://github.com/zeromq/libzmq/pull/2189
> >> > > >
> >> > > > Anything else we should mention?
> >> > > >
> >> > > >
> >> > > > On Nov 1, 2016 21:33, "Luca Boccassi" <luca.boccassi at gmail.com> wrote:
> >> > > >>
> >> > > >> Status update:
> >> > > >>
> >> > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on Github:
> >> > > >>
> >> > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6
> >> > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1
> >> > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1
> >> > > >>
> >> > > >> I'll send an email to the announce list shortly. As I wrote earlier
> >> > > >> I'll work to have proper release notes for the stable releases.
> >> > > >>
> >> > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0
> >> > > >> stable tomorrow by the end of the day, and czmq the day after.
> >> > > >>
> >> > > >> It's an aggressive schedule, but I would _really_ like to get CZMQ
> >> > > >> 4.0.0 in Debian and the transition freeze date is Saturday (ABI/API is
> >> > > >> borken so there needs to be a transition), and for that I need libzmq
> >> > > >> up before it.
> >> > > >>
> >> > > >> Any objections?
> >> > > >>
> >> > > >> I've also noticed that not all the libzmq socket options are available
> >> > > >> in CZMQ, so this gives me some time to fix that.
> >> > > >>
> >> > > >>
> >> > > >> On 1 November 2016 at 14:48, Doron Somech <somdoron at gmail.com> wrote:
> >> > > >> > Great news!
> >> > > >> >
> >> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi <luca.boccassi at gmail.com>
> >> > > >> > wrote:
> >> > > >> >>
> >> > > >> >> Status update:
> >> > > >> >>
> >> > > >> >> - v2 APIs are gone from CZMQ:
> >> > > >> >>   https://github.com/zeromq/czmq/pull/1531
> >> > > >> >>   https://github.com/zeromq/czmq/pull/1532
> >> > > >> >> - PR is out to bump the libtool version and changelog for libzmq:
> >> > > >> >>   https://github.com/zeromq/libzmq/pull/2184
> >> > > >> >> - PR is out to backport the zmq_msg_t fix to 4.1:
> >> > > >> >>   https://github.com/zeromq/zeromq4-1/pull/155
> >> > > >> >>
> >> > > >> >> Once it's all merged I will tag 4.2.0~rc1 first, then release 4.1.6
> >> > > >> >> from
> >> > > >> >> zeromq4-1 since quite a few fixes have accumulated. Then I'll send PRs
> >> > > >> >> to prepare for CZMQ 4.0.0~rc1.
> >> > > >> >>
> >> > > >> >> After the RCs are out, I'll work on the changelogs/NEWS files (help is
> >> > > >> >> appreciated!) as they have fallen dramatically behind.
> >> > > >> >>
> >> > > >> >> I'll also prepare more formal release notes for the stable rels, the
> >> > > >> >> RCs
> >> > > >> >> will have just a quick note since they are RCs.
> >> > > >> >>
> >> > > >> >> On Mon, 2016-10-31 at 23:47 +0000, Luca Boccassi wrote:
> >> > > >> >> > Cool!
> >> > > >> >> >
> >> > > >> >> > I can take care of it if you like. Tentative plan:
> >> > > >> >> >
> >> > > >> >> > Tomorrow push an RC1 for libzmq, then the pr to CZMQ to retire v2
> >> > > >> >> > APIs,
> >> > > >> >> > then the RC1 for CZMQ.
> >> > > >> >> >
> >> > > >> >> > If it's all good then a couple days later the finals. I would really
> >> > > >> >> > like
> >> > > >> >> > to make it for the debian 9 transition freeze which is Saturday.
> >> > > >> >> >
> >> > > >> >> > On Oct 31, 2016 22:23, "Doron Somech" <somdoron at gmail.com> wrote:
> >> > > >> >> >
> >> > > >> >> > > Sorry, yes, lets do it :)
> >> > > >> >> > >
> >> > > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" <luca.boccassi at gmail.com>
> >> > > >> >> > > wrote:
> >> > > >> >> > >
> >> > > >> >> > >> Ping :-)
> >> > > >> >> > >>
> >> > > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" <luca.boccassi at gmail.com>
> >> > > >> >> > >> wrote:
> >> > > >> >> > >>
> >> > > >> >> > >>> I have sent a solution for the alignment problem that solves the
> >> > > >> >> > >>> sigbus
> >> > > >> >> > >>> problem without breaking ABI compat (plus follow-up for VC++ -
> >> > > >> >> > >>> sorry
> >> > > >> >> > >>> Windows guys https://github.com/zeromq/libzmq/pull/2179 ).
> >> > > >> >> > >>>
> >> > > >> >> > >>> I tested the alignment and sigbus problem on x86_64 by enabling
> >> > > >> >> > >>> alignment check with:
> >> > > >> >> > >>>
> >> > > >> >> > >>> __asm__("pushf\norl $0x40000,(%rsp)\npopf");
> >> > > >> >> > >>>
> >> > > >> >> > >>> All was fine.
> >> > > >> >> > >>>
> >> > > >> >> > >>> I ran tests built from the zeromq4-1 repository against a shared
> >> > > >> >> > >>> lib
> >> > > >> >> > >>> from the head of libzmq repo, and they all run fine minus the
> >> > > >> >> > >>> ZMQ_REQ_CORRELATE one but that option was borken anyway.
> >> > > >> >> > >>>
> >> > > >> >> > >>> This allows us to do a release now, and then when we are ready we
> >> > > >> >> > >>> can do
> >> > > >> >> > >>> the ABI breakage, without blocking 4.2. Which is nice since it
> >> > > >> >> > >>> means
> >> > > >> >> > >>> it
> >> > > >> >> > >>> might make it for Debian 9!
> >> > > >> >> > >>>
> >> > > >> >> > >>> So, Doron et al, shall we do the bump this weekend?
> >> > > >> >> > >>>
> >> > > >> >> > >>> On Thu, 2016-10-20 at 17:12 -0500, Thomas Rodgers wrote:
> >> > > >> >> > >>> > I will have some time most likely the week of Nov6 (off for a
> >> > > >> >> > >>> > week
> >> > > >> >> > >>> > of
> >> > > >> >> > >>> C++
> >> > > >> >> > >>> > Committee 'fun') to test different message size alternatives.
> >> > > >> >> > >>> > I'll
> >> > > >> >> > >>> follow
> >> > > >> >> > >>> > up with my results here for consideration the next time we are
> >> > > >> >> > >>> inclined to
> >> > > >> >> > >>> > break the ABI compatibility :)
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > On Sunday, October 16, 2016, Brian Knox
> >> > > >> >> > >>> > <bknox at digitalocean.com>
> >> > > >> >> > >>> wrote:
> >> > > >> >> > >>> >
> >> > > >> >> > >>> > > A new stable version would definitely help me in my quest to
> >> > > >> >> > >>> > > get
> >> > > >> >> > >>> ZeroMQ
> >> > > >> >> > >>> > > support enabled by default in rsyslog in distros.
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > > On Sun, Oct 16, 2016 at 2:40 PM Doron Somech
> >> > > >> >> > >>> > > <somdoron at gmail.com>
> >> > > >> >> > >>> wrote:
> >> > > >> >> > >>> > >
> >> > > >> >> > >>> > >> I say lets bump.
> >> > > >> >> > >>> > >>
> >> > > >> >> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi"
> >> > > >> >> > >>> > >> <luca.boccassi at gmail.com>
> >> > > >> >> > >>> wrote:
> >> > > >> >> > >>> > >>
> >> > > >> >> > >>> > >>> As Thomas said, false sharing would be a real issue with
> >> > > >> >> > >>> > >>> 96.
> >> > > >> >> > >>> > >>>
> >> > > >> >> > >>> > >>> So given a release is long due, at this point I'd say to
> >> > > >> >> > >>> > >>> drop
> >> > > >> >> > >>> > >>> this
> >> > > >> >> > >>> for
> >> > > >> >> > >>> > >>> the moment.
> >> > > >> >> > >>> > >>>
> >> > > >> >> > >>> > >>> What do we do for the change to union for zmq_msg_t? Bump
> >> > > >> >> > >>> > >>> ABI
> >> > > >> >> > >>> version or
> >> > > >> >> > >>> > >>> not?
> >> > > >> >> > >>> > >>>
> >> > > >> >> > >>> > >>> On Thu, 2016-10-06 at 09:53 +0300, Doron Somech wrote:
> >> > > >> >> > >>> > >>> > No new socket type, I worked at the time on binary
> >> > > >> >> > >>> > >>> > message
> >> > > >> >> > >>> > >>> > type,
> >> > > >> >> > >>> might
> >> > > >> >> > >>> > >>> > complete it sometime, but it is not urgent.
> >> > > >> >> > >>> > >>> >
> >> > > >> >> > >>> > >>> > If there is a lot of performance penalty we can give it
> >> > > >> >> > >>> > >>> > up,
> >> > > >> >> > >>> > >>> > I
> >> > > >> >> > >>> will
> >> > > >> >> > >>> > >>> > find another solution for the Radio-Dish.
> >> > > >> >> > >>> > >>> >
> >> > > >> >> > >>> > >>> > What about 96 bytes? same penalty?
> >> > > >> >> > >>> > >>> >
> >> > > >> >> > >>> > >>> > Regarding the binding, I'm not sure.
> >> > > >> >> > >>> > >>> >
> >> > > >> >> > >>> > >>> > On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi <
> >> > > >> >> > >>> luca.boccassi at gmail.com>
> >> > > >> >> > >>> > >>> wrote:
> >> > > >> >> > >>> > >>> > > On Tue, 2016-09-27 at 09:41 +0300, Doron Somech wrote:
> >> > > >> >> > >>> > >>> > >> Sorry for the late response, increasing the msg_t
> >> > > >> >> > >>> > >>> > >> structure
> >> > > >> >> > >>> will be
> >> > > >> >> > >>> > >>> > >> great, however this will require changing a lot of
> >> > > >> >> > >>> > >>> > >> binding.
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > I think I remember we need it for the new socket types,
> >> > > >> >> > >>> > >>> > > is
> >> > > >> >> > >>> > >>> > > that
> >> > > >> >> > >>> > >>> correct?
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > There is a large performance penalty (intuitively due
> >> > > >> >> > >>> > >>> > > to
> >> > > >> >> > >>> > >>> > > not
> >> > > >> >> > >>> fitting
> >> > > >> >> > >>> > >>> > > into a single cache line anymore, but haven't ran
> >> > > >> >> > >>> perf/cachegrind),
> >> > > >> >> > >>> > >>> and
> >> > > >> >> > >>> > >>> > > the throughput with vsm type messages goes down by 4%
> >> > > >> >> > >>> > >>> > > (min)
> >> > > >> >> > >>> and 20%
> >> > > >> >> > >>> > >>> > > (max) for TCP, and 36% (min) 38 (max) for inproc, which
> >> > > >> >> > >>> > >>> > > is
> >> > > >> >> > >>> quite a
> >> > > >> >> > >>> > >>> lot,
> >> > > >> >> > >>> > >>> > > so we need to be sure it's worth it.
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > Regarding the bindings, after a quick search on the
> >> > > >> >> > >>> > >>> > > Github
> >> > > >> >> > >>> org, I
> >> > > >> >> > >>> > >>> could
> >> > > >> >> > >>> > >>> > > only see:
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/
> >> > > >> >> > >>> > >>> ffi/api.lua#L144
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L
> >> > > >> >> > >>> 177
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > Other bindings just import zmq.h. Did I miss any?
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > >> Sorry for disappearing, baby and full time job is a
> >> > > >> >> > >>> > >>> > >> lot
> >> > > >> >> > >>> > >>> > >> :-),
> >> > > >> >> > >>> > >>> hopefully
> >> > > >> >> > >>> > >>> > >> I'm back...
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > > No worries, perfectly understandable :-)
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>> > >> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi <
> >> > > >> >> > >>> > >>> luca.boccassi at gmail.com> wrote:
> >> > > >> >> > >>> > >>> > >> > Sorry, I meant if we go with (1), not (2), we might
> >> > > >> >> > >>> > >>> > >> > bump
> >> > > >> >> > >>> the size
> >> > > >> >> > >>> > >>> as
> >> > > >> >> > >>> > >>> > >> > well, since we are already doing another
> >> > > >> >> > >>> > >>> > >> > ABI-breaking
> >> > > >> >> > >>> change.
> >> > > >> >> > >>> > >>> > >> >
> >> > > >> >> > >>> > >>> > >> > I agree on the solution as well.
> >> > > >> >> > >>> > >>> > >> >
> >> > > >> >> > >>> > >>> > >> > On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens
> >> > > >> >> > >>> > >>> > >> > wrote:
> >> > > >> >> > >>> > >>> > >> >> I'm confused between the (1) and (2) choices, and
> >> > > >> >> > >>> > >>> > >> >> can't
> >> > > >> >> > >>> see where
> >> > > >> >> > >>> > >>> > >> >> bumping the message size fits.
> >> > > >> >> > >>> > >>> > >> >>
> >> > > >> >> > >>> > >>> > >> >> Nonetheless, I think bumping the size, fixing the
> >> > > >> >> > >>> > >>> > >> >> alignment
> >> > > >> >> > >>> > >>> issues,
> >> > > >> >> > >>> > >>> > >> >> and bumping the ABI version is the best solution
> >> > > >> >> > >>> > >>> > >> >> here.
> >> > > >> >> > >>> > >>> > >> >>
> >> > > >> >> > >>> > >>> > >> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi <
> >> > > >> >> > >>> > >>> luca.boccassi at gmail.com> wrote:
> >> > > >> >> > >>> > >>> > >> >> > I've given some more thoughts and testing to the
> >> > > >> >> > >>> alignment
> >> > > >> >> > >>> > >>> issue. I can
> >> > > >> >> > >>> > >>> > >> >> > reproduce the problem by enabling alignment
> >> > > >> >> > >>> > >>> > >> >> > checks
> >> > > >> >> > >>> > >>> > >> >> > on
> >> > > >> >> > >>> x86 too.
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > But most importantly, I think we cannot get away
> >> > > >> >> > >>> > >>> > >> >> > from
> >> > > >> >> > >>> bumping
> >> > > >> >> > >>> > >>> the ABI
> >> > > >> >> > >>> > >>> > >> >> > with this fix, however we rearrange it, simply
> >> > > >> >> > >>> > >>> > >> >> > because
> >> > > >> >> > >>> > >>> applications need
> >> > > >> >> > >>> > >>> > >> >> > to be rebuilt against the new header to be fixed.
> >> > > >> >> > >>> > >>> > >> >> > A
> >> > > >> >> > >>> simple
> >> > > >> >> > >>> > >>> rebuild of
> >> > > >> >> > >>> > >>> > >> >> > the libzmq.so is not enough. And the way to do
> >> > > >> >> > >>> > >>> > >> >> > this
> >> > > >> >> > >>> > >>> > >> >> > is
> >> > > >> >> > >>> to bump
> >> > > >> >> > >>> > >>> the ABI
> >> > > >> >> > >>> > >>> > >> >> > so that distros can schedule transitions and
> >> > > >> >> > >>> > >>> > >> >> > rebuilds
> >> > > >> >> > >>> and so
> >> > > >> >> > >>> > >>> on.
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > So the choice list is now restricted to:
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > 1) Bump ABI
> >> > > >> >> > >>> > >>> > >> >> > 2) Revert the fix and leave everything broken on
> >> > > >> >> > >>> > >>> > >> >> > sparc64
> >> > > >> >> > >>> and
> >> > > >> >> > >>> > >>> some
> >> > > >> >> > >>> > >>> > >> >> > aarch64 (rpi3 seems not to be affected, must
> >> > > >> >> > >>> > >>> > >> >> > depend
> >> > > >> >> > >>> > >>> > >> >> > on
> >> > > >> >> > >>> the SoC
> >> > > >> >> > >>> > >>> flavour)
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > If we go with 2, we might as well get 2 birds
> >> > > >> >> > >>> > >>> > >> >> > with
> >> > > >> >> > >>> > >>> > >> >> > one
> >> > > >> >> > >>> stone
> >> > > >> >> > >>> > >>> and bump
> >> > > >> >> > >>> > >>> > >> >> > the zmq_msg_t size to 128 as we have talked about
> >> > > >> >> > >>> > >>> > >> >> > in
> >> > > >> >> > >>> > >>> > >> >> > the
> >> > > >> >> > >>> past.
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > Doron, this would help with the new UDP based
> >> > > >> >> > >>> > >>> > >> >> > socket
> >> > > >> >> > >>> types
> >> > > >> >> > >>> > >>> right?
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > Pros of bumping msg size:
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > - we can get rid of the malloc() in the lmsg type
> >> > > >> >> > >>> > >>> > >> >> > case
> >> > > >> >> > >>> as all
> >> > > >> >> > >>> > >>> the data
> >> > > >> >> > >>> > >>> > >> >> > will fit
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > Cons:
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > - for the vsm/cmsg type cases (for most
> >> > > >> >> > >>> > >>> > >> >> > architectures
> >> > > >> >> > >>> anyway)
> >> > > >> >> > >>> > >>> it won't
> >> > > >> >> > >>> > >>> > >> >> > fit anymore into a single cacheline
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > Given all this, I'd say we should go for it.
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > Opinions?
> >> > > >> >> > >>> > >>> > >> >> >
> >> > > >> >> > >>> > >>> > >> >> > On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi
> >> > > >> >> > >>> > >>> > >> >> > wrote:
> >> > > >> >> > >>> > >>> > >> >> >> Hello,
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> Trying to give some thoughts again on the libzmq
> >> > > >> >> > >>> > >>> > >> >> >> 4.2
> >> > > >> >> > >>> release.
> >> > > >> >> > >>> > >>> It's
> >> > > >> >> > >>> > >>> > >> >> >> really long overdue!
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> The main issue from my point of view is this
> >> > > >> >> > >>> > >>> > >> >> >> change:
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> https://github.com/zeromq/libzmq/commit/
> >> > > >> >> > >>> > >>> d9fb1d36ff2008966af538f722a1f4ab158dbf64
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> -typedef struct zmq_msg_t {unsigned char _
> >> > > >> >> > >>> > >>> > >> >> >> [64];}
> >> > > >> >> > >>> zmq_msg_t;
> >> > > >> >> > >>> > >>> > >> >> >>  +/* union here ensures correct alignment on
> >> > > >> >> > >>> architectures
> >> > > >> >> > >>> > >>> that require
> >> > > >> >> > >>> > >>> > >> >> >> it, e.g.
> >> > > >> >> > >>> > >>> > >> >> >>  + * SPARC
> >> > > >> >> > >>> > >>> > >> >> >>  + */
> >> > > >> >> > >>> > >>> > >> >> >>  +typedef union zmq_msg_t {unsigned char _ [64];
> >> > > >> >> > >>> > >>> > >> >> >> void
> >> > > >> >> > >>> *p; }
> >> > > >> >> > >>> > >>> zmq_msg_t;
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> This is flagged by the common ABI checkers tools
> >> > > >> >> > >>> > >>> > >> >> >> as
> >> > > >> >> > >>> > >>> > >> >> >> an
> >> > > >> >> > >>> ABI
> >> > > >> >> > >>> > >>> breakage
> >> > > >> >> > >>> > >>> > >> >> >> (see: http://abi-laboratory.pro/trac
> >> > > >> >> > >>> ker/timeline/zeromq/ ).
> >> > > >> >> > >>> > >>> And it makes
> >> > > >> >> > >>> > >>> > >> >> >> sense from this point of view: if some
> >> > > >> >> > >>> > >>> > >> >> >> applications
> >> > > >> >> > >>> > >>> > >> >> >> on
> >> > > >> >> > >>> some
> >> > > >> >> > >>> > >>> > >> >> >> architectures are broken due to wrong alignment,
> >> > > >> >> > >>> > >>> > >> >> >> they
> >> > > >> >> > >>> would
> >> > > >> >> > >>> > >>> need to be
> >> > > >> >> > >>> > >>> > >> >> >> rebuilt, and the way to ensure that is to bump
> >> > > >> >> > >>> > >>> > >> >> >> the
> >> > > >> >> > >>> > >>> > >> >> >> ABI
> >> > > >> >> > >>> > >>> "current" digit
> >> > > >> >> > >>> > >>> > >> >> >> to make sure maintainers do a rebuild.
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> On the other hand, signaling an ABI breakage is
> >> > > >> >> > >>> > >>> > >> >> >> a
> >> > > >> >> > >>> > >>> > >> >> >> pain,
> >> > > >> >> > >>> and a
> >> > > >> >> > >>> > >>> cause of
> >> > > >> >> > >>> > >>> > >> >> >> major churn for packagers and maintainers. It
> >> > > >> >> > >>> > >>> > >> >> >> means
> >> > > >> >> > >>> > >>> > >> >> >> for
> >> > > >> >> > >>> > >>> example a new
> >> > > >> >> > >>> > >>> > >> >> >> package has to be created (eg: libzmq5 ->
> >> > > >> >> > >>> > >>> > >> >> >> libzmq6),
> >> > > >> >> > >>> > >>> > >> >> >> and
> >> > > >> >> > >>> a
> >> > > >> >> > >>> > >>> transition has
> >> > > >> >> > >>> > >>> > >> >> >> to be started and all reverse dependencies need
> >> > > >> >> > >>> > >>> > >> >> >> to
> >> > > >> >> > >>> > >>> > >> >> >> be
> >> > > >> >> > >>> > >>> rebuilt. And if
> >> > > >> >> > >>> > >>> > >> >> >> this is pointless for all save a few corner
> >> > > >> >> > >>> > >>> > >> >> >> cases
> >> > > >> >> > >>> > >>> > >> >> >> (eg
> >> > > >> >> > >>> SPARC64
> >> > > >> >> > >>> > >>> as for
> >> > > >> >> > >>> > >>> > >> >> >> above) it's all quite frustrating.
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> So we have a choice to make before we release
> >> > > >> >> > >>> > >>> > >> >> >> 4.2,
> >> > > >> >> > >>> > >>> > >> >> >> four
> >> > > >> >> > >>> > >>> possibilities as
> >> > > >> >> > >>> > >>> > >> >> >> far as I can see:
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> 1) Ignore the ABI checkers and get yelled at by
> >> > > >> >> > >>> maintainers
> >> > > >> >> > >>> > >>> and
> >> > > >> >> > >>> > >>> > >> >> >> packagers. Also the SPARC64 users will most
> >> > > >> >> > >>> > >>> > >> >> >> likely
> >> > > >> >> > >>> > >>> > >> >> >> NOT
> >> > > >> >> > >>> get
> >> > > >> >> > >>> > >>> their bug
> >> > > >> >> > >>> > >>> > >> >> >> fixed
> >> > > >> >> > >>> > >>> > >> >> >> 2) Bump ABI revision to 6 and get yelled at by
> >> > > >> >> > >>> maintainers
> >> > > >> >> > >>> > >>> and packagers
> >> > > >> >> > >>> > >>> > >> >> >> 3) Revert the above change and postpone it to
> >> > > >> >> > >>> > >>> > >> >> >> when
> >> > > >> >> > >>> > >>> > >> >> >> we
> >> > > >> >> > >>> have a
> >> > > >> >> > >>> > >>> more
> >> > > >> >> > >>> > >>> > >> >> >> generally useful reason to break ABI (bump
> >> > > >> >> > >>> > >>> > >> >> >> zmq_msg_t
> >> > > >> >> > >>> from 64
> >> > > >> >> > >>> > >>> to 128
> >> > > >> >> > >>> > >>> > >> >> >> bytes for example, Doron?)
> >> > > >> >> > >>> > >>> > >> >> >> 4) Try to be clever and revert the above change
> >> > > >> >> > >>> > >>> > >> >> >> and
> >> > > >> >> > >>> > >>> > >> >> >> use
> >> > > >> >> > >>> > >>> something like
> >> > > >> >> > >>> > >>> > >> >> >> #pragma pack(8). This will fool the ABI checkers
> >> > > >> >> > >>> > >>> > >> >> >> (I
> >> > > >> >> > >>> tried
> >> > > >> >> > >>> > >>> it), and given
> >> > > >> >> > >>> > >>> > >> >> >> that typedef is only used externally to allocate
> >> > > >> >> > >>> > >>> > >> >> >> the
> >> > > >> >> > >>> right
> >> > > >> >> > >>> > >>> size it
> >> > > >> >> > >>> > >>> > >> >> >> shouldn't actually affect anything, apart from
> >> > > >> >> > >>> > >>> > >> >> >> the
> >> > > >> >> > >>> users of
> >> > > >> >> > >>> > >>> SPARC64
> >> > > >> >> > >>> > >>> > >> >> >> which should get the bugfix with this too. This
> >> > > >> >> > >>> > >>> > >> >> >> is
> >> > > >> >> > >>> > >>> > >> >> >> very
> >> > > >> >> > >>> > >>> sneaky :-)
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> CC'ing Lazslo, the Debian maintainer, given what
> >> > > >> >> > >>> > >>> > >> >> >> we
> >> > > >> >> > >>> choose to
> >> > > >> >> > >>> > >>> do might
> >> > > >> >> > >>> > >>> > >> >> >> result in a lot of work for him :-)
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> Opinions?
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> Kind regards,
> >> > > >> >> > >>> > >>> > >> >> >> Luca Boccassi
> >> > > >> >> > >>> > >>> > >> >> >>
> >> > > >> >> > >>> > >>> > >> >> >> 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.
> >> > > >> >> > >>> > >>> > >> >> >> >
> >> > > >> >> > >>> > >>> > >> >> >> > 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.
> >> > > >> >> > >>> > >>> > >> >> >> > - 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.
> >> > > >> >> > >>> > >>> > >> >> >> >
> >> > > >> >> > >>> > >>> > >> >> >> > I think this will work and also let us
> >> > > >> >> > >>> > >>> > >> >> >> > gracefully
> >> > > >> >> > >>> > >>> deprecate/switch off
> >> > > >> >> > >>> > >>> > >> >> >> > the downloads box.
> >> > > >> >> > >>> > >>> > >> >> >> >
> >> > > >> >> > >>> > >>> > >> >> >> > -Pieter
> >> > > >> >> > >>> > >>> > >> >> >> >
> >> > > >> >> > >>> > >>> > >> >> >> > _______________________________________________
> >> > > >> >> > >>> > >>> > >> >> >> > 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
> >> > > >> >> > >>> > >>> > >> >
> >> > > >> >> > >>> > >>> > >> >
> >> > > >> >> > >>> > >>> > >
> >> > > >> >> > >>> > >>>
> >> > > >> >> > >>> > >>> _______________________________________________
> >> > > >> >> > >>> > >> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20161105/28cbb447/attachment.sig>