[zeromq-dev] ZeroMQ 4.2 release, planning

Luca Boccassi luca.boccassi at gmail.com
Sat Aug 13 17:59:35 CEST 2016


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:


-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/tracker/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
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 :-)


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

-------------- 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/20160813/f4223783/attachment.sig>

More information about the zeromq-dev mailing list