Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Final status update (hopefully!), CZMQ 4.0.1 is now out:

https://github.com/zeromq/czmq/releases/tag/v4.0.1

Apologies for the troubles with the draft system, it should be now all
right.

On Tue, 2016-11-08 at 17:33 +, Luca Boccassi wrote:
> Further status update:
> 
> I found out that the implementation of the DRAFT APIs build mechanism in
> zproject/czmq had a bug, and the DRAFT symbols were leaked as global in
> the shared library even when DRAFT APIs are disabled (note that libzmq
> is fine due to the differences between C and C++).
> 
> I fixed this now for *nix (help from Windows MS VC++ experts would be
> appreciated!):
> 
> https://github.com/zeromq/czmq/pull/1549/files
> https://github.com/zeromq/czmq/pull/1550/files
> 
> I consider this bad enough to warrant a bugfix release, before it causes
> troubles for distributions. I patched it manually in Debian before
> kicking off the transition libczmq3 -> libczmq4.
> 
> If there are no objections I intend to push CZMQ 4.0.1 tomorrow. Then we
> can breath for a while :-)
> 
> On Sat, 2016-11-05 at 07:44 +, Luca Boccassi 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 +, 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 +, 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 +, 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  
> > > > > 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"  
> > > > > > 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  
> > > > > >> wrote:
> > > > > >> > Great news!
> > > > > >> >
> > > > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> > > > > >> > 
> > > > > >> > 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 
> > > > > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

I have updated the page for libzmq, but I do not have permissions to
edit the CZMQ one.

Doron, may I please get permissions so I can update:

http://czmq.zeromq.org/page:get-the-software

On Sat, 2016-11-05 at 10:14 +0100, Michal Vyskocil wrote:
> Hi,
> 
> No problem, I know this is a lot of work.
> 
> drafts sound even better than forks.
> 
> Btw I love first changelog entry
> 
> Michal
> 
> Dne 5. 11. 2016 10:02 napsal uživatel "Luca Boccassi" <
> luca.bocca...@gmail.com>:
> 
> > 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 
> > 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 +, 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 +, 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 +, 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.bocca...@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" 
> > 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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Michal Vyskocil]

Hi,

No problem, I know this is a lot of work.

drafts sound even better than forks.

Btw I love first changelog entry

Michal

Dne 5. 11. 2016 10:02 napsal uživatel "Luca Boccassi" <
luca.bocca...@gmail.com>:

> 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 
> 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 +, 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 +, 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 +, 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.bocca...@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" 
> 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 
> wrote:
> > >> > > >> > Great news!
> > >> > > >> >
> > >> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi <
> luca.bocca...@gmail.com>
> > >> > > >> > wrote:
> > >> > > >> >>
> > >> > > >> >> Status update:
> > >> > > >> >>
> > >> > > >> >> - v2 APIs are gone from CZMQ:
> > >> > > >> >>   https://github.com/zeromq/czmq/pull/1531
> > >> > > >> >>   

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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  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 +, 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 +, 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 +, 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  
> >> > > 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"  
> >> > > > 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  
> >> > > >> wrote:
> >> > > >> > Great news!
> >> > > >> >
> >> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> >> > > >> > 
> >> > > >> > 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 
> >> > > >> >> 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Michal Vyskocil]

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  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 +, 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 +, 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 +, 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  
>> > > 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"  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  wrote:
>> > > >> > Great news!
>> > > >> >
>> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
>> > > >> > 
>> > > >> > 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 +, 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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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 +, 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 +, 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 +, 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  
> > > 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"  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  wrote:
> > > >> > Great news!
> > > >> >
> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> > > >> > 
> > > >> > 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 +, 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"  wrote:
> > > >> >> >
> > > >> >> > > Sorry, yes, lets do it :)
> > > >> >> > >
> > > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
> > > >> >> > > 
> > > >> 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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 +, 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 +, 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  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"  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  wrote:
> > >> > Great news!
> > >> >
> > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> > >> > 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 +, 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"  wrote:
> > >> >> >
> > >> >> > > Sorry, yes, lets do it :)
> > >> >> > >
> > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
> > >> >> > > 
> > >> >> > > wrote:
> > >> >> > >
> > >> >> > >> Ping :-)
> > >> >> > >>
> > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
> > >> >> > >> 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:
> > >> >> > >>>
> > >> >> > >>> 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Ahmad Zawawi]

Awesome :)

2016-11-04 12:52 GMT+02:00 Doron Somech :

> Great news
>
> On Nov 4, 2016 12:46 PM, "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 +, 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 
>> 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" 
>> 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 
>> wrote:
>> > >> > Great news!
>> > >> >
>> > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi <
>> luca.bocca...@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 +, 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" 
>> wrote:
>> > >> >> >
>> > >> >> > > Sorry, yes, lets do it :)
>> > >> >> > >
>> > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" <
>> luca.bocca...@gmail.com>
>> > >> >> > > wrote:
>> > >> >> > >
>> > >> >> > >> Ping :-)
>> > >> >> > >>
>> > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" <
>> luca.bocca...@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 $0x4,(%rsp)\npopf");
>> > >> >> > >>>
>> > >> >> > >>> All was fine.

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Great news

On Nov 4, 2016 12:46 PM, "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 +, 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 
> 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"  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  wrote:
> > >> > Great news!
> > >> >
> > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi <
> luca.bocca...@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 +, 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" 
> wrote:
> > >> >> >
> > >> >> > > Sorry, yes, lets do it :)
> > >> >> > >
> > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" <
> luca.bocca...@gmail.com>
> > >> >> > > wrote:
> > >> >> > >
> > >> >> > >> Ping :-)
> > >> >> > >>
> > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" <
> luca.bocca...@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 $0x4,(%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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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 +, 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  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"  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  wrote:
> >> > Great news!
> >> >
> >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> >> > 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 +, 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"  wrote:
> >> >> >
> >> >> > > Sorry, yes, lets do it :)
> >> >> > >
> >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
> >> >> > > wrote:
> >> >> > >
> >> >> > >> Ping :-)
> >> >> > >>
> >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
> >> >> > >> 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 $0x4,(%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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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  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"  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  wrote:
>> > Great news!
>> >
>> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
>> > 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 +, 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"  wrote:
>> >> >
>> >> > > Sorry, yes, lets do it :)
>> >> > >
>> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
>> >> > > wrote:
>> >> > >
>> >> > >> Ping :-)
>> >> > >>
>> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
>> >> > >> 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 $0x4,(%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
>> >> > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

It's also useful for distributions, as it gives a clear cut on when ABI
is broken and bumped, which shouldn't happen often. Remember every ABI
incompatible change in a library is days or weeks worth of work for
Linux distros.

Also many enterprise users want a stable, released version that they can
control and use without any changes, backward-compatible or not.

Of course then there are many who are happy to use the latest head of
the git tree, and that's great as well.

Different uses for different users, but we are in a good spot as we can
easily support both.

On Wed, 2016-11-02 at 14:26 +0100, Kevin Sapper wrote:
> In general czmq and zyre are stable on master. Cutting releases IMO 
> makes only sense to push API changes, i.e. 
> draft->stable->deprecated->removed.
> 
> On Mi, Nov 2, 2016 at 2:08 , Wes Young  wrote:
> > +1
> > 
> > with the pace czmq and zyre are beginning to move at, unless we start 
> > cutting releases every few weeks/months we’re probably using this 
> > methodology for a bit while things evolve and settle.. [which is OK, 
> > should make it easier to actually cut releases if anything]
> > 
> > it’d be nice to have something more stable to regularly point to, 
> > but i don’t think we’re there yet.. (i pretty much cut pyzyre to 
> > work like this when it builds the czmq bindings[1], just updating the 
> > commits and sha1’s, which is a little more manual, but keeps things 
> > chugging along).
> > 
> > [1] 
> > https://github.com/wesyoung/pyzyre/blob/master/buildutils/czmq/fetch.py#L33
> > 
> >>  On Nov 1, 2016, at 7:52 PM, Brian Knox  
> >> wrote:
> >> 
> >>  No objections here - been using czmq off various commits off head 
> >> for over a year anyway
> > 
> > --
> > wes
> > wesyoung.me
> > 
> > ___
> > 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




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

In general czmq and zyre are stable on master. Cutting releases IMO 
makes only sense to push API changes, i.e. 
draft->stable->deprecated->removed.


On Mi, Nov 2, 2016 at 2:08 , Wes Young  wrote:

+1

with the pace czmq and zyre are beginning to move at, unless we start 
cutting releases every few weeks/months we’re probably using this 
methodology for a bit while things evolve and settle.. [which is OK, 
should make it easier to actually cut releases if anything]


it’d be nice to have something more stable to regularly point to, 
but i don’t think we’re there yet.. (i pretty much cut pyzyre to 
work like this when it builds the czmq bindings[1], just updating the 
commits and sha1’s, which is a little more manual, but keeps things 
chugging along).


[1] 
https://github.com/wesyoung/pyzyre/blob/master/buildutils/czmq/fetch.py#L33


 On Nov 1, 2016, at 7:52 PM, Brian Knox  
wrote:


 No objections here - been using czmq off various commits off head 
for over a year anyway


--
wes
wesyoung.me

___
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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Ahmad Zawawi]

Thanks for your great efforts in releasing 4.1.6 and 4.2. I just also
updated https://github.com/azawawi/SwiftyZeroMQ to include a compiled
ZeroMQ v4.1.6 for iOS, macOS, tvOS and watchOS :)

Regards,
Ahmad

2016-11-02 15:08 GMT+02:00 Wes Young :

> +1
>
> with the pace czmq and zyre are beginning to move at, unless we start
> cutting releases every few weeks/months we’re probably using this
> methodology for a bit while things evolve and settle.. [which is OK, should
> make it easier to actually cut releases if anything]
>
> it’d be nice to have something more stable to regularly point to, but i
> don’t think we’re there yet.. (i pretty much cut pyzyre to work like this
> when it builds the czmq bindings[1], just updating the commits and sha1’s,
> which is a little more manual, but keeps things chugging along).
>
> [1] https://github.com/wesyoung/pyzyre/blob/master/buildutils/
> czmq/fetch.py#L33
>
> > On Nov 1, 2016, at 7:52 PM, Brian Knox  wrote:
> >
> > No objections here - been using czmq off various commits off head for
> over a year anyway
>
> --
> wes
> wesyoung.me
>
>
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Wes Young]

+1

with the pace czmq and zyre are beginning to move at, unless we start cutting 
releases every few weeks/months we’re probably using this methodology for a bit 
while things evolve and settle.. [which is OK, should make it easier to 
actually cut releases if anything]

it’d be nice to have something more stable to regularly point to, but i don’t 
think we’re there yet.. (i pretty much cut pyzyre to work like this when it 
builds the czmq bindings[1], just updating the commits and sha1’s, which is a 
little more manual, but keeps things chugging along).

[1] https://github.com/wesyoung/pyzyre/blob/master/buildutils/czmq/fetch.py#L33

> On Nov 1, 2016, at 7:52 PM, Brian Knox  wrote:
> 
> No objections here - been using czmq off various commits off head for over a 
> year anyway

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Brian Knox]

No objections here - been using czmq off various commits off head for over
a year anyway ;)

On Tue, Nov 1, 2016 at 5:33 PM Luca Boccassi 
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  wrote:
> > Great news!
> >
> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> > 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 +, 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"  wrote:
> >> >
> >> > > Sorry, yes, lets do it :)
> >> > >
> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
> >> > > wrote:
> >> > >
> >> > >> Ping :-)
> >> > >>
> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
> >> > >> 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 $0x4,(%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  >
> >> > >>> 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
> >> > >>> > > 
> >> > >>> wrote:
> >> > >>> > >
> >> > >>> > >> I say lets bump.
> >> > >>> > >>
> >> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi"
> >> > >>> > >> 
> >> > >>> wrote:
> >> > >>> > >>
> >> > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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  wrote:
> Great news!
>
> On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
> 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 +, 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"  wrote:
>> >
>> > > Sorry, yes, lets do it :)
>> > >
>> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
>> > > wrote:
>> > >
>> > >> Ping :-)
>> > >>
>> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
>> > >> 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 $0x4,(%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 
>> > >>> 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
>> > >>> > > 
>> > >>> wrote:
>> > >>> > >
>> > >>> > >> I say lets bump.
>> > >>> > >>
>> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi"
>> > >>> > >> 
>> > >>> 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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Great news!

On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi 
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 +, 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"  wrote:
> >
> > > Sorry, yes, lets do it :)
> > >
> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" 
> wrote:
> > >
> > >> Ping :-)
> > >>
> > >> On Oct 28, 2016 18:48, "Luca Boccassi" 
> 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 $0x4,(%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 
> > >>> 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  >
> > >>> wrote:
> > >>> > >
> > >>> > >> I say lets bump.
> > >>> > >>
> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi"  >
> > >>> 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.bocca...@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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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 +, 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"  wrote:
> 
> > Sorry, yes, lets do it :)
> >
> > On Oct 31, 2016 11:44 PM, "Luca Boccassi"  wrote:
> >
> >> Ping :-)
> >>
> >> On Oct 28, 2016 18:48, "Luca Boccassi"  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 $0x4,(%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 
> >>> 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 
> >>> wrote:
> >>> > >
> >>> > >> I say lets bump.
> >>> > >>
> >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi" 
> >>> 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.bocca...@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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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"  wrote:

> Sorry, yes, lets do it :)
>
> On Oct 31, 2016 11:44 PM, "Luca Boccassi"  wrote:
>
>> Ping :-)
>>
>> On Oct 28, 2016 18:48, "Luca Boccassi"  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 $0x4,(%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 
>>> 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 
>>> wrote:
>>> > >
>>> > >> I say lets bump.
>>> > >>
>>> > >> On Oct 15, 2016 20:32, "Luca Boccassi" 
>>> 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.bocca...@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.bocca...@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.
>>> > >>> > >> >
>>> > >>> > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Sorry, yes, lets do it :)

On Oct 31, 2016 11:44 PM, "Luca Boccassi"  wrote:

> Ping :-)
>
> On Oct 28, 2016 18:48, "Luca Boccassi"  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 $0x4,(%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  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 
>> wrote:
>> > >
>> > >> I say lets bump.
>> > >>
>> > >> On Oct 15, 2016 20:32, "Luca Boccassi" 
>> 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.bocca...@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#L177
>> > >>> > >
>> > >>> > > 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.bocca...@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.bocca...@gmail.com> wrote:

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Ping :-)

On Oct 28, 2016 18:48, "Luca Boccassi"  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 $0x4,(%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  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 
> wrote:
> > >
> > >> I say lets bump.
> > >>
> > >> On Oct 15, 2016 20:32, "Luca Boccassi" 
> 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.bocca...@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#L177
> > >>> > >
> > >>> > > 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.bocca...@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.bocca...@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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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 $0x4,(%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  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  wrote:
> >
> >> I say lets bump.
> >>
> >> On Oct 15, 2016 20:32, "Luca Boccassi"  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 
> >>> 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#L177
> >>> > >
> >>> > > 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.bocca...@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.bocca...@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
> 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

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  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  wrote:
>
>> I say lets bump.
>>
>> On Oct 15, 2016 20:32, "Luca Boccassi"  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 
>>> 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#L177
>>> > >
>>> > > 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.bocca...@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.bocca...@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
>>> > >> >> >

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Brian Knox]

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  wrote:

> I say lets bump.
>
> On Oct 15, 2016 20:32, "Luca Boccassi"  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 
> 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#L177
> > >
> > > 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.bocca...@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.bocca...@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];} 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

I say lets bump.

On Oct 15, 2016 20:32, "Luca Boccassi"  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 
> 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#L177
> > >
> > > 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.bocca...@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.bocca...@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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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  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#L177
> >
> > 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  
> >> 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 
> >> >>  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/tracker/timeline/zeromq/ ). And it 
> >> >> >> makes
> >> >> >> sense from this 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

>
> Looking forward to seeing the benchmarks on that idea!


The most direct way to do so (and most relevant to libzmq, rather than my
toy implementation over Boost Asio) would be to make the change in the
existing zmq code base and benchmark it with a few sizes. I will make some
time to do that over the next week or so.

On Fri, Oct 7, 2016 at 7:28 AM, Manuel Amador (Rudd-O) 
wrote:

> On 10/06/2016 02:03 PM, Thomas Rodgers wrote:
> >
> > What about 96 bytes? same penalty?
> >
> >
> > If you are going to bump the size to > 64 bytes (x86 cache line size),
> > it likely should be rounded up to to 128 bytes, so as to eliminate any
> > potential for false sharing on architectures with 64 byte cache lines.
> >
> > Having said that, I've been playing with an experimental C++
> > implementation of ZMTP using much larger fixed message struct sizes of
> > ~512 bytes. It's nothing more than a toy implementation at this point
> > and I don't have any real perf numbers, but my reasoning for the
> > larger message size is that ZMTP has explicit optimization for small
> > messages of < 256 bytes. A size > 256 bytes accommodates all small
> > ZMTP messages without an extra allocation and indirection and the
> > reference counting overhead of the large message type (all potentially
> > much more expensive operations than the cost of simply being larger
> > than a cache line), along with message metadata, and likely a decent
> > fraction of "large" ZMTP messages.
>
> Looking forward to seeing the benchmarks on that idea!
>
>
> --
> Rudd-O
> http://rudd-o.com/
>
>
>
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Manuel Amador (Rudd-O)]

On 10/06/2016 02:03 PM, Thomas Rodgers wrote:
>
> What about 96 bytes? same penalty?
>
>
> If you are going to bump the size to > 64 bytes (x86 cache line size),
> it likely should be rounded up to to 128 bytes, so as to eliminate any
> potential for false sharing on architectures with 64 byte cache lines.
>
> Having said that, I've been playing with an experimental C++
> implementation of ZMTP using much larger fixed message struct sizes of
> ~512 bytes. It's nothing more than a toy implementation at this point
> and I don't have any real perf numbers, but my reasoning for the
> larger message size is that ZMTP has explicit optimization for small
> messages of < 256 bytes. A size > 256 bytes accommodates all small
> ZMTP messages without an extra allocation and indirection and the
> reference counting overhead of the large message type (all potentially
> much more expensive operations than the cost of simply being larger
> than a cache line), along with message metadata, and likely a decent
> fraction of "large" ZMTP messages.

Looking forward to seeing the benchmarks on that idea!


-- 
Rudd-O
http://rudd-o.com/




signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

>
> What about 96 bytes? same penalty?


If you are going to bump the size to > 64 bytes (x86 cache line size), it
likely should be rounded up to to 128 bytes, so as to eliminate any
potential for false sharing on architectures with 64 byte cache lines.

Having said that, I've been playing with an experimental C++ implementation
of ZMTP using much larger fixed message struct sizes of ~512 bytes. It's
nothing more than a toy implementation at this point and I don't have any
real perf numbers, but my reasoning for the larger message size is that
ZMTP has explicit optimization for small messages of < 256 bytes. A size >
256 bytes accommodates all small ZMTP messages without an extra allocation
and indirection and the reference counting overhead of the large message
type (all potentially much more expensive operations than the cost of
simply being larger than a cache line), along with message metadata, and
likely a decent fraction of "large" ZMTP messages.



On Thu, Oct 6, 2016 at 1:53 AM, 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 
> 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#L177
> >
> > 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 
> 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.bocca...@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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

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  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#L177
>
> 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  
>> 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  
>> >> 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/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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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#L177

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  
> 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  
> >> 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/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
> >> >> fixed
> >> >> 2) Bump ABI revision to 6 and get yelled at by maintainers and 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Benjamin Henrion]

On Thu, Sep 29, 2016 at 12:13 PM, Pieter Hintjens  wrote:
> Hopefully you're back! :-)
>
> I see a lot of good stiff since May. Especially getting properly
> signed downloads via HTTPS from github, rather than HTTP from
> zeromq.org.

How do you make automated mirrors with HTTP?

With FTP, it is one command.

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

Hopefully you're back! :-)

I see a lot of good stiff since May. Especially getting properly
signed downloads via HTTPS from github, rather than HTTP from
zeromq.org.

Let's try to get a 4.2 release out :-)

-Pieter

On Tue, Sep 27, 2016 at 8:41 AM, 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.
>
> Sorry for disappearing, baby and full time job is a lot :-), hopefully
> I'm back...
>
>
>
>
> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi  
> 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  
>>> 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/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
>>> >> 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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Sorry for the late response, increasing the msg_t structure will be
great, however this will require changing a lot of binding.

Sorry for disappearing, baby and full time job is a lot :-), hopefully
I'm back...




On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi  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  
>> 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/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
>> >> 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.
>> >> >
>> >> > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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  
> 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/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
> >> 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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

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  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/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
>> 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 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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/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
> 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
> > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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/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
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@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Sounds like a plan :-)

On Fri, 2016-06-17 at 16:04 +0300, Doron Somech wrote:
> Leave to someone else who use libzmq on widows and would like to
> contribute?
> On Jun 17, 2016 15:56, "Luca Boccassi"  wrote:
> 
> > Thanks!
> >
> > That page mentions Windows exes. What do we do about those?
> >
> > On Fri, 2016-06-17 at 13:59 +0200, Pieter Hintjens wrote:
> > > Never mind, found it. You should be able to edit all pages in intro:
> > > in a few minutes...
> > >
> > > On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens  wrote:
> > > > Luca, what's your Wikidot login? I'll give you edit rights to that
> > page/site.
> > > >
> > > > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi <
> > luca.bocca...@gmail.com> wrote:
> > > >> The messages to the announce list have been sent, and are awaiting
> > > >> moderator approval.
> > > >>
> > > >> Pieter, Doron, how do we update the get-the-software page?
> > > >>
> > > >> http://zeromq.org/intro:get-the-software
> > > >>
> > > >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> > > >>> Second try went better :-) And on the 4.1 branch it was all right the
> > > >>> first time around. So it was probably just a CI hiccup.
> > > >>>
> > > >>> I'll send two separate messages to the announce list.
> > > >>>
> > > >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > > >>> > Something has short-circuited on Travis, and while the upload of
> > the
> > > >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page
> > just
> > > >>> > shows a error mark, and says to delete the zip file and upload it
> > again
> > > >>> > (but the zip is in the MD5 and SHA sums files).
> > > >>> >
> > > >>> > I've removed the generated files and I'm trying to run the job
> > again.
> > > >>> >
> > > >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > > >>> > > If you run into any trouble with the automatic travis release
> > feel free to
> > > >>> > > ping me via twitter or mail.
> > > >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <
> > luca.bocca...@gmail.com>:
> > > >>> > >
> > > >>> > > > Yep! It should be pretty smooth.
> > > >>> > > >
> > > >>> > > > Is there anything windows-specific to do when we do a release?
> > > >>> > > >
> > > >>> > > > If not, if it's ok for you and Doron, I'm fine with taking
> > care of
> > > >>> > > > bumping the ABI revision (only, since there were no
> > incompatible
> > > >>> > > > changes), finalizing the NEWS and pushing the tag in both
> > repos.
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> ___
> > > >> 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
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Leave to someone else who use libzmq on widows and would like to
contribute?
On Jun 17, 2016 15:56, "Luca Boccassi"  wrote:

> Thanks!
>
> That page mentions Windows exes. What do we do about those?
>
> On Fri, 2016-06-17 at 13:59 +0200, Pieter Hintjens wrote:
> > Never mind, found it. You should be able to edit all pages in intro:
> > in a few minutes...
> >
> > On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens  wrote:
> > > Luca, what's your Wikidot login? I'll give you edit rights to that
> page/site.
> > >
> > > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi <
> luca.bocca...@gmail.com> wrote:
> > >> The messages to the announce list have been sent, and are awaiting
> > >> moderator approval.
> > >>
> > >> Pieter, Doron, how do we update the get-the-software page?
> > >>
> > >> http://zeromq.org/intro:get-the-software
> > >>
> > >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> > >>> Second try went better :-) And on the 4.1 branch it was all right the
> > >>> first time around. So it was probably just a CI hiccup.
> > >>>
> > >>> I'll send two separate messages to the announce list.
> > >>>
> > >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > >>> > Something has short-circuited on Travis, and while the upload of
> the
> > >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page
> just
> > >>> > shows a error mark, and says to delete the zip file and upload it
> again
> > >>> > (but the zip is in the MD5 and SHA sums files).
> > >>> >
> > >>> > I've removed the generated files and I'm trying to run the job
> again.
> > >>> >
> > >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > >>> > > If you run into any trouble with the automatic travis release
> feel free to
> > >>> > > ping me via twitter or mail.
> > >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <
> luca.bocca...@gmail.com>:
> > >>> > >
> > >>> > > > Yep! It should be pretty smooth.
> > >>> > > >
> > >>> > > > Is there anything windows-specific to do when we do a release?
> > >>> > > >
> > >>> > > > If not, if it's ok for you and Doron, I'm fine with taking
> care of
> > >>> > > > bumping the ABI revision (only, since there were no
> incompatible
> > >>> > > > changes), finalizing the NEWS and pushing the tag in both
> repos.
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> ___
> > >> 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
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Thanks!

That page mentions Windows exes. What do we do about those?

On Fri, 2016-06-17 at 13:59 +0200, Pieter Hintjens wrote:
> Never mind, found it. You should be able to edit all pages in intro:
> in a few minutes...
> 
> On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens  wrote:
> > Luca, what's your Wikidot login? I'll give you edit rights to that 
> > page/site.
> >
> > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi  
> > wrote:
> >> The messages to the announce list have been sent, and are awaiting
> >> moderator approval.
> >>
> >> Pieter, Doron, how do we update the get-the-software page?
> >>
> >> http://zeromq.org/intro:get-the-software
> >>
> >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> >>> Second try went better :-) And on the 4.1 branch it was all right the
> >>> first time around. So it was probably just a CI hiccup.
> >>>
> >>> I'll send two separate messages to the announce list.
> >>>
> >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> >>> > Something has short-circuited on Travis, and while the upload of the
> >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page just
> >>> > shows a error mark, and says to delete the zip file and upload it again
> >>> > (but the zip is in the MD5 and SHA sums files).
> >>> >
> >>> > I've removed the generated files and I'm trying to run the job again.
> >>> >
> >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> >>> > > If you run into any trouble with the automatic travis release feel 
> >>> > > free to
> >>> > > ping me via twitter or mail.
> >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" 
> >>> > > :
> >>> > >
> >>> > > > Yep! It should be pretty smooth.
> >>> > > >
> >>> > > > Is there anything windows-specific to do when we do a release?
> >>> > > >
> >>> > > > If not, if it's ok for you and Doron, I'm fine with taking care of
> >>> > > > bumping the ABI revision (only, since there were no incompatible
> >>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> >>>
> >>>
> >>
> >>
> >>
> >> ___
> >> 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




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Thanks!

On Fri, 2016-06-17 at 15:22 +0300, Doron Somech wrote:
> Luca,  mails approved.
> On Jun 17, 2016 15:00, "Pieter Hintjens"  wrote:
> 
> > Never mind, found it. You should be able to edit all pages in intro:
> > in a few minutes...
> >
> > On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens  wrote:
> > > Luca, what's your Wikidot login? I'll give you edit rights to that
> > page/site.
> > >
> > > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi 
> > wrote:
> > >> The messages to the announce list have been sent, and are awaiting
> > >> moderator approval.
> > >>
> > >> Pieter, Doron, how do we update the get-the-software page?
> > >>
> > >> http://zeromq.org/intro:get-the-software
> > >>
> > >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> > >>> Second try went better :-) And on the 4.1 branch it was all right the
> > >>> first time around. So it was probably just a CI hiccup.
> > >>>
> > >>> I'll send two separate messages to the announce list.
> > >>>
> > >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > >>> > Something has short-circuited on Travis, and while the upload of the
> > >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page
> > just
> > >>> > shows a error mark, and says to delete the zip file and upload it
> > again
> > >>> > (but the zip is in the MD5 and SHA sums files).
> > >>> >
> > >>> > I've removed the generated files and I'm trying to run the job again.
> > >>> >
> > >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > >>> > > If you run into any trouble with the automatic travis release feel
> > free to
> > >>> > > ping me via twitter or mail.
> > >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <
> > luca.bocca...@gmail.com>:
> > >>> > >
> > >>> > > > Yep! It should be pretty smooth.
> > >>> > > >
> > >>> > > > Is there anything windows-specific to do when we do a release?
> > >>> > > >
> > >>> > > > If not, if it's ok for you and Doron, I'm fine with taking care
> > of
> > >>> > > > bumping the ABI revision (only, since there were no incompatible
> > >>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> ___
> > >> 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




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Luca,  mails approved.
On Jun 17, 2016 15:00, "Pieter Hintjens"  wrote:

> Never mind, found it. You should be able to edit all pages in intro:
> in a few minutes...
>
> On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens  wrote:
> > Luca, what's your Wikidot login? I'll give you edit rights to that
> page/site.
> >
> > On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi 
> wrote:
> >> The messages to the announce list have been sent, and are awaiting
> >> moderator approval.
> >>
> >> Pieter, Doron, how do we update the get-the-software page?
> >>
> >> http://zeromq.org/intro:get-the-software
> >>
> >> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> >>> Second try went better :-) And on the 4.1 branch it was all right the
> >>> first time around. So it was probably just a CI hiccup.
> >>>
> >>> I'll send two separate messages to the announce list.
> >>>
> >>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> >>> > Something has short-circuited on Travis, and while the upload of the
> >>> > tar.gz was successful, the zip upload was not. The "edit-tag" page
> just
> >>> > shows a error mark, and says to delete the zip file and upload it
> again
> >>> > (but the zip is in the MD5 and SHA sums files).
> >>> >
> >>> > I've removed the generated files and I'm trying to run the job again.
> >>> >
> >>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> >>> > > If you run into any trouble with the automatic travis release feel
> free to
> >>> > > ping me via twitter or mail.
> >>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" <
> luca.bocca...@gmail.com>:
> >>> > >
> >>> > > > Yep! It should be pretty smooth.
> >>> > > >
> >>> > > > Is there anything windows-specific to do when we do a release?
> >>> > > >
> >>> > > > If not, if it's ok for you and Doron, I'm fine with taking care
> of
> >>> > > > bumping the ABI revision (only, since there were no incompatible
> >>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> >>>
> >>>
> >>
> >>
> >>
> >> ___
> >> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

Never mind, found it. You should be able to edit all pages in intro:
in a few minutes...

On Fri, Jun 17, 2016 at 1:58 PM, Pieter Hintjens  wrote:
> Luca, what's your Wikidot login? I'll give you edit rights to that page/site.
>
> On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi  
> wrote:
>> The messages to the announce list have been sent, and are awaiting
>> moderator approval.
>>
>> Pieter, Doron, how do we update the get-the-software page?
>>
>> http://zeromq.org/intro:get-the-software
>>
>> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
>>> Second try went better :-) And on the 4.1 branch it was all right the
>>> first time around. So it was probably just a CI hiccup.
>>>
>>> I'll send two separate messages to the announce list.
>>>
>>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
>>> > Something has short-circuited on Travis, and while the upload of the
>>> > tar.gz was successful, the zip upload was not. The "edit-tag" page just
>>> > shows a error mark, and says to delete the zip file and upload it again
>>> > (but the zip is in the MD5 and SHA sums files).
>>> >
>>> > I've removed the generated files and I'm trying to run the job again.
>>> >
>>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
>>> > > If you run into any trouble with the automatic travis release feel free 
>>> > > to
>>> > > ping me via twitter or mail.
>>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" 
>>> > > :
>>> > >
>>> > > > Yep! It should be pretty smooth.
>>> > > >
>>> > > > Is there anything windows-specific to do when we do a release?
>>> > > >
>>> > > > If not, if it's ok for you and Doron, I'm fine with taking care of
>>> > > > bumping the ABI revision (only, since there were no incompatible
>>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
>>>
>>>
>>
>>
>>
>> ___
>> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

Luca, what's your Wikidot login? I'll give you edit rights to that page/site.

On Fri, Jun 17, 2016 at 1:54 PM, Luca Boccassi  wrote:
> The messages to the announce list have been sent, and are awaiting
> moderator approval.
>
> Pieter, Doron, how do we update the get-the-software page?
>
> http://zeromq.org/intro:get-the-software
>
> On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
>> Second try went better :-) And on the 4.1 branch it was all right the
>> first time around. So it was probably just a CI hiccup.
>>
>> I'll send two separate messages to the announce list.
>>
>> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
>> > Something has short-circuited on Travis, and while the upload of the
>> > tar.gz was successful, the zip upload was not. The "edit-tag" page just
>> > shows a error mark, and says to delete the zip file and upload it again
>> > (but the zip is in the MD5 and SHA sums files).
>> >
>> > I've removed the generated files and I'm trying to run the job again.
>> >
>> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
>> > > If you run into any trouble with the automatic travis release feel free 
>> > > to
>> > > ping me via twitter or mail.
>> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" 
>> > > :
>> > >
>> > > > Yep! It should be pretty smooth.
>> > > >
>> > > > Is there anything windows-specific to do when we do a release?
>> > > >
>> > > > If not, if it's ok for you and Doron, I'm fine with taking care of
>> > > > bumping the ABI revision (only, since there were no incompatible
>> > > > changes), finalizing the NEWS and pushing the tag in both repos.
>>
>>
>
>
>
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

The messages to the announce list have been sent, and are awaiting
moderator approval.

Pieter, Doron, how do we update the get-the-software page?

http://zeromq.org/intro:get-the-software

On Fri, 2016-06-17 at 12:47 +0100, Luca Boccassi wrote:
> Second try went better :-) And on the 4.1 branch it was all right the
> first time around. So it was probably just a CI hiccup.
> 
> I'll send two separate messages to the announce list.
> 
> On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> > Something has short-circuited on Travis, and while the upload of the
> > tar.gz was successful, the zip upload was not. The "edit-tag" page just
> > shows a error mark, and says to delete the zip file and upload it again
> > (but the zip is in the MD5 and SHA sums files).
> > 
> > I've removed the generated files and I'm trying to run the job again.
> > 
> > On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > > If you run into any trouble with the automatic travis release feel free to
> > > ping me via twitter or mail.
> > > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" 
> > > :
> > > 
> > > > Yep! It should be pretty smooth.
> > > >
> > > > Is there anything windows-specific to do when we do a release?
> > > >
> > > > If not, if it's ok for you and Doron, I'm fine with taking care of
> > > > bumping the ABI revision (only, since there were no incompatible
> > > > changes), finalizing the NEWS and pushing the tag in both repos.
> 
> 




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Second try went better :-) And on the 4.1 branch it was all right the
first time around. So it was probably just a CI hiccup.

I'll send two separate messages to the announce list.

On Fri, 2016-06-17 at 12:28 +0100, Luca Boccassi wrote:
> Something has short-circuited on Travis, and while the upload of the
> tar.gz was successful, the zip upload was not. The "edit-tag" page just
> shows a error mark, and says to delete the zip file and upload it again
> (but the zip is in the MD5 and SHA sums files).
> 
> I've removed the generated files and I'm trying to run the job again.
> 
> On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> > If you run into any trouble with the automatic travis release feel free to
> > ping me via twitter or mail.
> > Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" :
> > 
> > > Yep! It should be pretty smooth.
> > >
> > > Is there anything windows-specific to do when we do a release?
> > >
> > > If not, if it's ok for you and Doron, I'm fine with taking care of
> > > bumping the ABI revision (only, since there were no incompatible
> > > changes), finalizing the NEWS and pushing the tag in both repos.




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Something has short-circuited on Travis, and while the upload of the
tar.gz was successful, the zip upload was not. The "edit-tag" page just
shows a error mark, and says to delete the zip file and upload it again
(but the zip is in the MD5 and SHA sums files).

I've removed the generated files and I'm trying to run the job again.

On Thu, 2016-06-16 at 21:56 +0200, Kevin Sapper wrote:
> If you run into any trouble with the automatic travis release feel free to
> ping me via twitter or mail.
> Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" :
> 
> > Yep! It should be pretty smooth.
> >
> > Is there anything windows-specific to do when we do a release?
> >
> > If not, if it's ok for you and Doron, I'm fine with taking care of
> > bumping the ABI revision (only, since there were no incompatible
> > changes), finalizing the NEWS and pushing the tag in both repos.


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Great  Luca,  go ahead.
On Jun 16, 2016 22:56, "Kevin Sapper"  wrote:

> If you run into any trouble with the automatic travis release feel free to
> ping me via twitter or mail.
> Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi"  >:
>
>> Yep! It should be pretty smooth.
>>
>> Is there anything windows-specific to do when we do a release?
>>
>> If not, if it's ok for you and Doron, I'm fine with taking care of
>> bumping the ABI revision (only, since there were no incompatible
>> changes), finalizing the NEWS and pushing the tag in both repos.
>>
>> On Thu, 2016-06-16 at 18:55 +0200, Pieter Hintjens wrote:
>> > Sounds good. Shall we make these pilots for the new release process?
>> >
>> > On Thu, Jun 16, 2016 at 1:10 PM, Luca Boccassi 
>> wrote:
>> > > Hi,
>> > >
>> > > During the Brussels meetup/hackaday I backported Kevin's Github+Travis
>> > > release to zerom4-1 and zeromq4-x.
>> > >
>> > > We have quite a few bug fixes queued up there since the last stable
>> > > releases a year ago - shall we do a bugfix release for both? Those
>> would
>> > > be 4.1.5 and 4.0.8.
>> > >
>> > > Just to be sure, I've verified with abi-compliance-checker [1] that
>> > > there was no ABI breakage with the respective stable versions.
>> > >
>> > > Kind regards,
>> > > Luca Boccassi
>> > >
>> > > [1] https://github.com/lvc/abi-compliance-checker
>> > >
>> > > On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
>> > >> The deployment has a couple of constraints (see .travis.yml ->
>> deploy: on:
>> > >> ).
>> > >> One constraint is the repo MUST be "zeromq/libzmq". If we port this
>> to
>> > >> zeromq4-x and zeromq4-1
>> > >> we need to adjust this or remove this constraint altogether.
>> > >>
>> > >> 2016-05-09 13:04 GMT+02:00 Luca Boccassi :
>> > >>
>> > >> > Awesome, thanks!
>> > >> >
>> > >> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have
>> to
>> > >> > push the tags corresponding to the last commit of each previous
>> release,
>> > >> > right? It might make moving all downloadable to Github a much
>> easier
>> > >> > process.
>> > >> >
>> > >> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
>> > >> > > On libzmq master it's now possible to let travis automatically
>> deploy
>> > >> > > artifacts. The deployment is triggered if a new tag is created.
>> I've
>> > >> > > created a test release and tag[1] to see if it is working
>> properly. The
>> > >> > > files that are available under this release have been deploy by
>> travis.
>> > >> > >
>> > >> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
>> > >> > >
>> > >> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi <
>> luca.bocca...@gmail.com>:
>> > >> > >
>> > >> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
>> > >> > > > > Hi,
>> > >> > > > >
>> > >> > > > > Just for a curiosity - the content of packaging/debian
>> collide with
>> > >> > > > > standard Debian packaging? It is intentionally there to not
>> clash, so
>> > >> > > > maybe
>> > >> > > > > solve this problem. Either by not generating them, either by
>> defying
>> > >> > > > safer
>> > >> > > > > location.
>> > >> > > >
>> > >> > > > It's not a problem with the location, it's just that the
>> Debian source
>> > >> > > > package will end up having packaging stuff duplicated and with
>> > >> > different
>> > >> > > > content: 2 changelogs, 2 control files, etc.
>> > >> > > >
>> > >> > > > But again this is exactly why make dist exists - having that
>> generated
>> > >> > > > packaging code in the repository is useful, no need to remove
>> it.
>> > >> > > >
>> > >> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
>> > >> > > > > > One note, 'make dist' always fails the first few times
>> because
>> > >> > files
>> > >> > > > > > are missing. Keep this in mind. The git tarball has the
>> great
>> > >> > > > > > advantage of never failing. (And since it makes tarballs
>> look like
>> > >> > git
>> > >> > > > > > clones it gives the same experience to all developers.)
>> > >> > > > > >
>> > >> > > > > > I'd vote for killing 'make dist'. It also makes us
>> dependent on
>> > >> > > > autotools.
>> > >> > > > >
>> > >> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
>> > >> > > > > and ./autogen.sh; ./configure; make dist works just fine.
>> > >> > > > > It was broken a while ago, but I fixed it, and now the CI
>> tests that
>> > >> > it
>> > >> > > > > works.
>> > >> > > > >
>> > >> > > > > Besides, IMHO there are 2 big problems with just tarring up
>> the git
>> > >> > > > > repo.
>> > >> > > > >
>> > >> > > > > First of all, it doesn't remove the dependency, it just
>> moves it
>> > >> > down to
>> > >> > > > > the user. Which means we'll start getting bug reports that
>> are due to
>> > >> > > > > the different versions of autotools or cmake used (and there
>> are a
>> > >> > lot!
>> > >> > > > > ).
>> > >> > > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

If you run into any trouble with the automatic travis release feel free to
ping me via twitter or mail.
Am 16.06.2016 9:31 nachm. schrieb "Luca Boccassi" :

> Yep! It should be pretty smooth.
>
> Is there anything windows-specific to do when we do a release?
>
> If not, if it's ok for you and Doron, I'm fine with taking care of
> bumping the ABI revision (only, since there were no incompatible
> changes), finalizing the NEWS and pushing the tag in both repos.
>
> On Thu, 2016-06-16 at 18:55 +0200, Pieter Hintjens wrote:
> > Sounds good. Shall we make these pilots for the new release process?
> >
> > On Thu, Jun 16, 2016 at 1:10 PM, Luca Boccassi 
> wrote:
> > > Hi,
> > >
> > > During the Brussels meetup/hackaday I backported Kevin's Github+Travis
> > > release to zerom4-1 and zeromq4-x.
> > >
> > > We have quite a few bug fixes queued up there since the last stable
> > > releases a year ago - shall we do a bugfix release for both? Those
> would
> > > be 4.1.5 and 4.0.8.
> > >
> > > Just to be sure, I've verified with abi-compliance-checker [1] that
> > > there was no ABI breakage with the respective stable versions.
> > >
> > > Kind regards,
> > > Luca Boccassi
> > >
> > > [1] https://github.com/lvc/abi-compliance-checker
> > >
> > > On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
> > >> The deployment has a couple of constraints (see .travis.yml ->
> deploy: on:
> > >> ).
> > >> One constraint is the repo MUST be "zeromq/libzmq". If we port this to
> > >> zeromq4-x and zeromq4-1
> > >> we need to adjust this or remove this constraint altogether.
> > >>
> > >> 2016-05-09 13:04 GMT+02:00 Luca Boccassi :
> > >>
> > >> > Awesome, thanks!
> > >> >
> > >> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have
> to
> > >> > push the tags corresponding to the last commit of each previous
> release,
> > >> > right? It might make moving all downloadable to Github a much easier
> > >> > process.
> > >> >
> > >> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> > >> > > On libzmq master it's now possible to let travis automatically
> deploy
> > >> > > artifacts. The deployment is triggered if a new tag is created.
> I've
> > >> > > created a test release and tag[1] to see if it is working
> properly. The
> > >> > > files that are available under this release have been deploy by
> travis.
> > >> > >
> > >> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> > >> > >
> > >> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi  >:
> > >> > >
> > >> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > Just for a curiosity - the content of packaging/debian
> collide with
> > >> > > > > standard Debian packaging? It is intentionally there to not
> clash, so
> > >> > > > maybe
> > >> > > > > solve this problem. Either by not generating them, either by
> defying
> > >> > > > safer
> > >> > > > > location.
> > >> > > >
> > >> > > > It's not a problem with the location, it's just that the Debian
> source
> > >> > > > package will end up having packaging stuff duplicated and with
> > >> > different
> > >> > > > content: 2 changelogs, 2 control files, etc.
> > >> > > >
> > >> > > > But again this is exactly why make dist exists - having that
> generated
> > >> > > > packaging code in the repository is useful, no need to remove
> it.
> > >> > > >
> > >> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > >> > > > > > One note, 'make dist' always fails the first few times
> because
> > >> > files
> > >> > > > > > are missing. Keep this in mind. The git tarball has the
> great
> > >> > > > > > advantage of never failing. (And since it makes tarballs
> look like
> > >> > git
> > >> > > > > > clones it gives the same experience to all developers.)
> > >> > > > > >
> > >> > > > > > I'd vote for killing 'make dist'. It also makes us
> dependent on
> > >> > > > autotools.
> > >> > > > >
> > >> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > >> > > > > and ./autogen.sh; ./configure; make dist works just fine.
> > >> > > > > It was broken a while ago, but I fixed it, and now the CI
> tests that
> > >> > it
> > >> > > > > works.
> > >> > > > >
> > >> > > > > Besides, IMHO there are 2 big problems with just tarring up
> the git
> > >> > > > > repo.
> > >> > > > >
> > >> > > > > First of all, it doesn't remove the dependency, it just moves
> it
> > >> > down to
> > >> > > > > the user. Which means we'll start getting bug reports that
> are due to
> > >> > > > > the different versions of autotools or cmake used (and there
> are a
> > >> > lot!
> > >> > > > > ).
> > >> > > > >
> > >> > > > > But most importantly, the tarball will ship stuff that
> shouldn't be
> > >> > > > > shipped, which is a huge problem for distribution packagers.
> For
> > >> > > > > example, in CZMQ, the packaging bit would be 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Yep! It should be pretty smooth.

Is there anything windows-specific to do when we do a release?

If not, if it's ok for you and Doron, I'm fine with taking care of
bumping the ABI revision (only, since there were no incompatible
changes), finalizing the NEWS and pushing the tag in both repos.

On Thu, 2016-06-16 at 18:55 +0200, Pieter Hintjens wrote:
> Sounds good. Shall we make these pilots for the new release process?
> 
> On Thu, Jun 16, 2016 at 1:10 PM, Luca Boccassi  
> wrote:
> > Hi,
> >
> > During the Brussels meetup/hackaday I backported Kevin's Github+Travis
> > release to zerom4-1 and zeromq4-x.
> >
> > We have quite a few bug fixes queued up there since the last stable
> > releases a year ago - shall we do a bugfix release for both? Those would
> > be 4.1.5 and 4.0.8.
> >
> > Just to be sure, I've verified with abi-compliance-checker [1] that
> > there was no ABI breakage with the respective stable versions.
> >
> > Kind regards,
> > Luca Boccassi
> >
> > [1] https://github.com/lvc/abi-compliance-checker
> >
> > On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
> >> The deployment has a couple of constraints (see .travis.yml -> deploy: on:
> >> ).
> >> One constraint is the repo MUST be "zeromq/libzmq". If we port this to
> >> zeromq4-x and zeromq4-1
> >> we need to adjust this or remove this constraint altogether.
> >>
> >> 2016-05-09 13:04 GMT+02:00 Luca Boccassi :
> >>
> >> > Awesome, thanks!
> >> >
> >> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
> >> > push the tags corresponding to the last commit of each previous release,
> >> > right? It might make moving all downloadable to Github a much easier
> >> > process.
> >> >
> >> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> >> > > On libzmq master it's now possible to let travis automatically deploy
> >> > > artifacts. The deployment is triggered if a new tag is created. I've
> >> > > created a test release and tag[1] to see if it is working properly. The
> >> > > files that are available under this release have been deploy by travis.
> >> > >
> >> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> >> > >
> >> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi :
> >> > >
> >> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > Just for a curiosity - the content of packaging/debian collide with
> >> > > > > standard Debian packaging? It is intentionally there to not clash, 
> >> > > > > so
> >> > > > maybe
> >> > > > > solve this problem. Either by not generating them, either by 
> >> > > > > defying
> >> > > > safer
> >> > > > > location.
> >> > > >
> >> > > > It's not a problem with the location, it's just that the Debian 
> >> > > > source
> >> > > > package will end up having packaging stuff duplicated and with
> >> > different
> >> > > > content: 2 changelogs, 2 control files, etc.
> >> > > >
> >> > > > But again this is exactly why make dist exists - having that 
> >> > > > generated
> >> > > > packaging code in the repository is useful, no need to remove it.
> >> > > >
> >> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> >> > > > > > One note, 'make dist' always fails the first few times because
> >> > files
> >> > > > > > are missing. Keep this in mind. The git tarball has the great
> >> > > > > > advantage of never failing. (And since it makes tarballs look 
> >> > > > > > like
> >> > git
> >> > > > > > clones it gives the same experience to all developers.)
> >> > > > > >
> >> > > > > > I'd vote for killing 'make dist'. It also makes us dependent on
> >> > > > autotools.
> >> > > > >
> >> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> >> > > > > and ./autogen.sh; ./configure; make dist works just fine.
> >> > > > > It was broken a while ago, but I fixed it, and now the CI tests 
> >> > > > > that
> >> > it
> >> > > > > works.
> >> > > > >
> >> > > > > Besides, IMHO there are 2 big problems with just tarring up the git
> >> > > > > repo.
> >> > > > >
> >> > > > > First of all, it doesn't remove the dependency, it just moves it
> >> > down to
> >> > > > > the user. Which means we'll start getting bug reports that are due 
> >> > > > > to
> >> > > > > the different versions of autotools or cmake used (and there are a
> >> > lot!
> >> > > > > ).
> >> > > > >
> >> > > > > But most importantly, the tarball will ship stuff that shouldn't be
> >> > > > > shipped, which is a huge problem for distribution packagers. For
> >> > > > > example, in CZMQ, the packaging bit would be shipped. That would
> >> > break
> >> > > > > many things in the package build process, and the distro maintainer
> >> > (ie:
> >> > > > > me :-) ) would have to take the shipped tarball and sanitize it,
> >> > nuking
> >> > > > > all extraneous bits. This should not be necessary! That's exactly 
> >> > > > > the
> >> > > > > reason "make dist" 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

Sounds good. Shall we make these pilots for the new release process?

On Thu, Jun 16, 2016 at 1:10 PM, Luca Boccassi  wrote:
> Hi,
>
> During the Brussels meetup/hackaday I backported Kevin's Github+Travis
> release to zerom4-1 and zeromq4-x.
>
> We have quite a few bug fixes queued up there since the last stable
> releases a year ago - shall we do a bugfix release for both? Those would
> be 4.1.5 and 4.0.8.
>
> Just to be sure, I've verified with abi-compliance-checker [1] that
> there was no ABI breakage with the respective stable versions.
>
> Kind regards,
> Luca Boccassi
>
> [1] https://github.com/lvc/abi-compliance-checker
>
> On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
>> The deployment has a couple of constraints (see .travis.yml -> deploy: on:
>> ).
>> One constraint is the repo MUST be "zeromq/libzmq". If we port this to
>> zeromq4-x and zeromq4-1
>> we need to adjust this or remove this constraint altogether.
>>
>> 2016-05-09 13:04 GMT+02:00 Luca Boccassi :
>>
>> > Awesome, thanks!
>> >
>> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
>> > push the tags corresponding to the last commit of each previous release,
>> > right? It might make moving all downloadable to Github a much easier
>> > process.
>> >
>> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
>> > > On libzmq master it's now possible to let travis automatically deploy
>> > > artifacts. The deployment is triggered if a new tag is created. I've
>> > > created a test release and tag[1] to see if it is working properly. The
>> > > files that are available under this release have been deploy by travis.
>> > >
>> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
>> > >
>> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi :
>> > >
>> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
>> > > > > Hi,
>> > > > >
>> > > > > Just for a curiosity - the content of packaging/debian collide with
>> > > > > standard Debian packaging? It is intentionally there to not clash, so
>> > > > maybe
>> > > > > solve this problem. Either by not generating them, either by defying
>> > > > safer
>> > > > > location.
>> > > >
>> > > > It's not a problem with the location, it's just that the Debian source
>> > > > package will end up having packaging stuff duplicated and with
>> > different
>> > > > content: 2 changelogs, 2 control files, etc.
>> > > >
>> > > > But again this is exactly why make dist exists - having that generated
>> > > > packaging code in the repository is useful, no need to remove it.
>> > > >
>> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
>> > > > > > One note, 'make dist' always fails the first few times because
>> > files
>> > > > > > are missing. Keep this in mind. The git tarball has the great
>> > > > > > advantage of never failing. (And since it makes tarballs look like
>> > git
>> > > > > > clones it gives the same experience to all developers.)
>> > > > > >
>> > > > > > I'd vote for killing 'make dist'. It also makes us dependent on
>> > > > autotools.
>> > > > >
>> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
>> > > > > and ./autogen.sh; ./configure; make dist works just fine.
>> > > > > It was broken a while ago, but I fixed it, and now the CI tests that
>> > it
>> > > > > works.
>> > > > >
>> > > > > Besides, IMHO there are 2 big problems with just tarring up the git
>> > > > > repo.
>> > > > >
>> > > > > First of all, it doesn't remove the dependency, it just moves it
>> > down to
>> > > > > the user. Which means we'll start getting bug reports that are due to
>> > > > > the different versions of autotools or cmake used (and there are a
>> > lot!
>> > > > > ).
>> > > > >
>> > > > > But most importantly, the tarball will ship stuff that shouldn't be
>> > > > > shipped, which is a huge problem for distribution packagers. For
>> > > > > example, in CZMQ, the packaging bit would be shipped. That would
>> > break
>> > > > > many things in the package build process, and the distro maintainer
>> > (ie:
>> > > > > me :-) ) would have to take the shipped tarball and sanitize it,
>> > nuking
>> > > > > all extraneous bits. This should not be necessary! That's exactly the
>> > > > > reason "make dist" exists.
>> > > > >
>> > > > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens 
>> > wrote:
>> > > > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
>> > > > luca.bocca...@gmail.com>
>> > > > > wrote:
>> > > > > > >
>> > > > > > >> Is any of the API I marked as draft actually ready for release?
>> > > > > > >
>> > > > > > > Even so, leave it 'draft' until it's actually being used.
>> > Changing
>> > > > > > > minds is expensive otherwise.
>> > > > > > >
>> > > > > > >> So should we use branches instead for bugfix releases?
>> > > > > > >
>> > > > > > > All fixes to master. In the extraordinary case where a bugfix
>> > release
>> > > > > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Hi,

During the Brussels meetup/hackaday I backported Kevin's Github+Travis
release to zerom4-1 and zeromq4-x.

We have quite a few bug fixes queued up there since the last stable
releases a year ago - shall we do a bugfix release for both? Those would
be 4.1.5 and 4.0.8.

Just to be sure, I've verified with abi-compliance-checker [1] that
there was no ABI breakage with the respective stable versions.

Kind regards,
Luca Boccassi

[1] https://github.com/lvc/abi-compliance-checker

On Mon, 2016-05-09 at 13:36 +0200, Kevin Sapper wrote:
> The deployment has a couple of constraints (see .travis.yml -> deploy: on:
> ).
> One constraint is the repo MUST be "zeromq/libzmq". If we port this to
> zeromq4-x and zeromq4-1
> we need to adjust this or remove this constraint altogether.
> 
> 2016-05-09 13:04 GMT+02:00 Luca Boccassi :
> 
> > Awesome, thanks!
> >
> > So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
> > push the tags corresponding to the last commit of each previous release,
> > right? It might make moving all downloadable to Github a much easier
> > process.
> >
> > On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> > > On libzmq master it's now possible to let travis automatically deploy
> > > artifacts. The deployment is triggered if a new tag is created. I've
> > > created a test release and tag[1] to see if it is working properly. The
> > > files that are available under this release have been deploy by travis.
> > >
> > > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> > >
> > > 2016-05-04 11:34 GMT+02:00 Luca Boccassi :
> > >
> > > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > > > > Hi,
> > > > >
> > > > > Just for a curiosity - the content of packaging/debian collide with
> > > > > standard Debian packaging? It is intentionally there to not clash, so
> > > > maybe
> > > > > solve this problem. Either by not generating them, either by defying
> > > > safer
> > > > > location.
> > > >
> > > > It's not a problem with the location, it's just that the Debian source
> > > > package will end up having packaging stuff duplicated and with
> > different
> > > > content: 2 changelogs, 2 control files, etc.
> > > >
> > > > But again this is exactly why make dist exists - having that generated
> > > > packaging code in the repository is useful, no need to remove it.
> > > >
> > > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > > > > > One note, 'make dist' always fails the first few times because
> > files
> > > > > > are missing. Keep this in mind. The git tarball has the great
> > > > > > advantage of never failing. (And since it makes tarballs look like
> > git
> > > > > > clones it gives the same experience to all developers.)
> > > > > >
> > > > > > I'd vote for killing 'make dist'. It also makes us dependent on
> > > > autotools.
> > > > >
> > > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > > > > and ./autogen.sh; ./configure; make dist works just fine.
> > > > > It was broken a while ago, but I fixed it, and now the CI tests that
> > it
> > > > > works.
> > > > >
> > > > > Besides, IMHO there are 2 big problems with just tarring up the git
> > > > > repo.
> > > > >
> > > > > First of all, it doesn't remove the dependency, it just moves it
> > down to
> > > > > the user. Which means we'll start getting bug reports that are due to
> > > > > the different versions of autotools or cmake used (and there are a
> > lot!
> > > > > ).
> > > > >
> > > > > But most importantly, the tarball will ship stuff that shouldn't be
> > > > > shipped, which is a huge problem for distribution packagers. For
> > > > > example, in CZMQ, the packaging bit would be shipped. That would
> > break
> > > > > many things in the package build process, and the distro maintainer
> > (ie:
> > > > > me :-) ) would have to take the shipped tarball and sanitize it,
> > nuking
> > > > > all extraneous bits. This should not be necessary! That's exactly the
> > > > > reason "make dist" exists.
> > > > >
> > > > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens 
> > wrote:
> > > > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
> > > > luca.bocca...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> Is any of the API I marked as draft actually ready for release?
> > > > > > >
> > > > > > > Even so, leave it 'draft' until it's actually being used.
> > Changing
> > > > > > > minds is expensive otherwise.
> > > > > > >
> > > > > > >> So should we use branches instead for bugfix releases?
> > > > > > >
> > > > > > > All fixes to master. In the extraordinary case where a bugfix
> > release
> > > > > > > cannot be made from master, a branch could work. We never needed
> > this
> > > > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely
> > recommend
> > > > > > > against branches unless it's the only option. (And I think we've
> > > > > > > designed 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

Done!

With latest czmq travis script it is now possible to test the JNI bindings
and when tagging[1] deploying the android jar file automatically as its
done with the autotools tarballs :)

[1] https://github.com/zeromq/czmq/releases/tag/v3.0.3-testing

2016-05-10 23:58 GMT+02:00 Luca Boccassi :

> On Tue, 2016-05-10 at 13:05 +0200, Kevin Sapper wrote:
> > I just pushed changes to zproject and czmq to enable
> > automatic travis github releases as well. There is a
> > czmq test release that shows that it's working:
> >
> > https://github.com/zeromq/czmq/releases/tag/v3.0.3-testing
>
> Awesome, thanks!
>
> One fix we need to do (I can send a PR tomorrow if no one else beats me
> to it) is that the CMake stuff is not included in EXTRA_DIST, so it's
> missing from the release tarball.
>
> > 2016-05-10 5:16 GMT+02:00 Pieter Hintjens :
> >
> > > Kevin, this is really neat. :)
> > >
> > > On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill
> > >  wrote:
> > > > On 9/05/16 21:45, Kevin Sapper wrote:
> > > >>
> > > >> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> > > >
> > > >
> > > > Thanks for automating this.  It looks great.
> > > >
> > > > This gives us two downloads per release (each in .tar.gz and .zip):
> > > >
> > > >
> > >
> https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz
> > > > -- the Travis generated tarball (which I assume is prepared ready for
> > > > "./configure, make, make install")
> > > >
> > > > https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz
> > > > -- the GitHub auto-generated tarball from that release tag (which I
> > > assume
> > > > is what a git clone would give you, so a few extra steps required).
> > > >
> > > > So downloaders can choose the one they want.  (Including .zip file
> > > > variations of both.)
> > > >
> > > > Also of note, both URLs include a filename at the end, so "wget"
> > > > automatically does the right thing with the downloaded files (I just
> > > > tested).
> > > >
> > > > Ewen
> > > >
> > > > ___
> > > > 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
>
>
>
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

On Tue, 2016-05-10 at 13:05 +0200, Kevin Sapper wrote:
> I just pushed changes to zproject and czmq to enable
> automatic travis github releases as well. There is a
> czmq test release that shows that it's working:
> 
> https://github.com/zeromq/czmq/releases/tag/v3.0.3-testing

Awesome, thanks!

One fix we need to do (I can send a PR tomorrow if no one else beats me
to it) is that the CMake stuff is not included in EXTRA_DIST, so it's
missing from the release tarball.

> 2016-05-10 5:16 GMT+02:00 Pieter Hintjens :
> 
> > Kevin, this is really neat. :)
> >
> > On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill
> >  wrote:
> > > On 9/05/16 21:45, Kevin Sapper wrote:
> > >>
> > >> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> > >
> > >
> > > Thanks for automating this.  It looks great.
> > >
> > > This gives us two downloads per release (each in .tar.gz and .zip):
> > >
> > >
> > https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz
> > > -- the Travis generated tarball (which I assume is prepared ready for
> > > "./configure, make, make install")
> > >
> > > https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz
> > > -- the GitHub auto-generated tarball from that release tag (which I
> > assume
> > > is what a git clone would give you, so a few extra steps required).
> > >
> > > So downloaders can choose the one they want.  (Including .zip file
> > > variations of both.)
> > >
> > > Also of note, both URLs include a filename at the end, so "wget"
> > > automatically does the right thing with the downloaded files (I just
> > > tested).
> > >
> > > Ewen
> > >
> > > ___
> > > 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




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

I just pushed changes to zproject and czmq to enable
automatic travis github releases as well. There is a
czmq test release that shows that it's working:

https://github.com/zeromq/czmq/releases/tag/v3.0.3-testing

2016-05-10 5:16 GMT+02:00 Pieter Hintjens :

> Kevin, this is really neat. :)
>
> On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill
>  wrote:
> > On 9/05/16 21:45, Kevin Sapper wrote:
> >>
> >> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> >
> >
> > Thanks for automating this.  It looks great.
> >
> > This gives us two downloads per release (each in .tar.gz and .zip):
> >
> >
> https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz
> > -- the Travis generated tarball (which I assume is prepared ready for
> > "./configure, make, make install")
> >
> > https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz
> > -- the GitHub auto-generated tarball from that release tag (which I
> assume
> > is what a git clone would give you, so a few extra steps required).
> >
> > So downloaders can choose the one they want.  (Including .zip file
> > variations of both.)
> >
> > Also of note, both URLs include a filename at the end, so "wget"
> > automatically does the right thing with the downloaded files (I just
> > tested).
> >
> > Ewen
> >
> > ___
> > 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

Kevin, this is really neat. :)

On Mon, May 9, 2016 at 11:26 PM, Ewen McNeill
 wrote:
> On 9/05/16 21:45, Kevin Sapper wrote:
>>
>> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
>
>
> Thanks for automating this.  It looks great.
>
> This gives us two downloads per release (each in .tar.gz and .zip):
>
> https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz
> -- the Travis generated tarball (which I assume is prepared ready for
> "./configure, make, make install")
>
> https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz
> -- the GitHub auto-generated tarball from that release tag (which I assume
> is what a git clone would give you, so a few extra steps required).
>
> So downloaders can choose the one they want.  (Including .zip file
> variations of both.)
>
> Also of note, both URLs include a filename at the end, so "wget"
> automatically does the right thing with the downloaded files (I just
> tested).
>
> Ewen
>
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Ewen McNeill]

On 9/05/16 21:45, Kevin Sapper wrote:

[1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test


Thanks for automating this.  It looks great.

This gives us two downloads per release (each in .tar.gz and .zip):

https://github.com/zeromq/libzmq/releases/download/v4.0.2-test/zeromq-4.2.0.tar.gz
-- the Travis generated tarball (which I assume is prepared ready for 
"./configure, make, make install")


https://github.com/zeromq/libzmq/archive/v4.0.2-test.tar.gz
-- the GitHub auto-generated tarball from that release tag (which I 
assume is what a git clone would give you, so a few extra steps required).


So downloaders can choose the one they want.  (Including .zip file 
variations of both.)


Also of note, both URLs include a filename at the end, so "wget" 
automatically does the right thing with the downloaded files (I just 
tested).


Ewen
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

The deployment has a couple of constraints (see .travis.yml -> deploy: on:
).
One constraint is the repo MUST be "zeromq/libzmq". If we port this to
zeromq4-x and zeromq4-1
we need to adjust this or remove this constraint altogether.

2016-05-09 13:04 GMT+02:00 Luca Boccassi :

> Awesome, thanks!
>
> So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
> push the tags corresponding to the last commit of each previous release,
> right? It might make moving all downloadable to Github a much easier
> process.
>
> On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> > On libzmq master it's now possible to let travis automatically deploy
> > artifacts. The deployment is triggered if a new tag is created. I've
> > created a test release and tag[1] to see if it is working properly. The
> > files that are available under this release have been deploy by travis.
> >
> > [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> >
> > 2016-05-04 11:34 GMT+02:00 Luca Boccassi :
> >
> > > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > > > Hi,
> > > >
> > > > Just for a curiosity - the content of packaging/debian collide with
> > > > standard Debian packaging? It is intentionally there to not clash, so
> > > maybe
> > > > solve this problem. Either by not generating them, either by defying
> > > safer
> > > > location.
> > >
> > > It's not a problem with the location, it's just that the Debian source
> > > package will end up having packaging stuff duplicated and with
> different
> > > content: 2 changelogs, 2 control files, etc.
> > >
> > > But again this is exactly why make dist exists - having that generated
> > > packaging code in the repository is useful, no need to remove it.
> > >
> > > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > > > > One note, 'make dist' always fails the first few times because
> files
> > > > > are missing. Keep this in mind. The git tarball has the great
> > > > > advantage of never failing. (And since it makes tarballs look like
> git
> > > > > clones it gives the same experience to all developers.)
> > > > >
> > > > > I'd vote for killing 'make dist'. It also makes us dependent on
> > > autotools.
> > > >
> > > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > > > and ./autogen.sh; ./configure; make dist works just fine.
> > > > It was broken a while ago, but I fixed it, and now the CI tests that
> it
> > > > works.
> > > >
> > > > Besides, IMHO there are 2 big problems with just tarring up the git
> > > > repo.
> > > >
> > > > First of all, it doesn't remove the dependency, it just moves it
> down to
> > > > the user. Which means we'll start getting bug reports that are due to
> > > > the different versions of autotools or cmake used (and there are a
> lot!
> > > > ).
> > > >
> > > > But most importantly, the tarball will ship stuff that shouldn't be
> > > > shipped, which is a huge problem for distribution packagers. For
> > > > example, in CZMQ, the packaging bit would be shipped. That would
> break
> > > > many things in the package build process, and the distro maintainer
> (ie:
> > > > me :-) ) would have to take the shipped tarball and sanitize it,
> nuking
> > > > all extraneous bits. This should not be necessary! That's exactly the
> > > > reason "make dist" exists.
> > > >
> > > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens 
> wrote:
> > > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
> > > luca.bocca...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> Is any of the API I marked as draft actually ready for release?
> > > > > >
> > > > > > Even so, leave it 'draft' until it's actually being used.
> Changing
> > > > > > minds is expensive otherwise.
> > > > > >
> > > > > >> So should we use branches instead for bugfix releases?
> > > > > >
> > > > > > All fixes to master. In the extraordinary case where a bugfix
> release
> > > > > > cannot be made from master, a branch could work. We never needed
> this
> > > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely
> recommend
> > > > > > against branches unless it's the only option. (And I think we've
> > > > > > designed ourselves space to never need that option.)
> > > > > >
> > > > > >> 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.
> > > > > >
> > > > > > Seems Kevin has solved this, almost :)
> > > > > >
> > > > > > -Pieter
> > > > > ___
> > > > > 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
> > > > 

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

Awesome, thanks!

So now if we port this to zeromq4-x and zeromq4-1, we'll just have to
push the tags corresponding to the last commit of each previous release,
right? It might make moving all downloadable to Github a much easier
process.

On Mon, 2016-05-09 at 11:45 +0200, Kevin Sapper wrote:
> On libzmq master it's now possible to let travis automatically deploy
> artifacts. The deployment is triggered if a new tag is created. I've
> created a test release and tag[1] to see if it is working properly. The
> files that are available under this release have been deploy by travis.
> 
> [1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test
> 
> 2016-05-04 11:34 GMT+02:00 Luca Boccassi :
> 
> > On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > > Hi,
> > >
> > > Just for a curiosity - the content of packaging/debian collide with
> > > standard Debian packaging? It is intentionally there to not clash, so
> > maybe
> > > solve this problem. Either by not generating them, either by defying
> > safer
> > > location.
> >
> > It's not a problem with the location, it's just that the Debian source
> > package will end up having packaging stuff duplicated and with different
> > content: 2 changelogs, 2 control files, etc.
> >
> > But again this is exactly why make dist exists - having that generated
> > packaging code in the repository is useful, no need to remove it.
> >
> > > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > > > One note, 'make dist' always fails the first few times because files
> > > > are missing. Keep this in mind. The git tarball has the great
> > > > advantage of never failing. (And since it makes tarballs look like git
> > > > clones it gives the same experience to all developers.)
> > > >
> > > > I'd vote for killing 'make dist'. It also makes us dependent on
> > autotools.
> > >
> > > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > > and ./autogen.sh; ./configure; make dist works just fine.
> > > It was broken a while ago, but I fixed it, and now the CI tests that it
> > > works.
> > >
> > > Besides, IMHO there are 2 big problems with just tarring up the git
> > > repo.
> > >
> > > First of all, it doesn't remove the dependency, it just moves it down to
> > > the user. Which means we'll start getting bug reports that are due to
> > > the different versions of autotools or cmake used (and there are a lot!
> > > ).
> > >
> > > But most importantly, the tarball will ship stuff that shouldn't be
> > > shipped, which is a huge problem for distribution packagers. For
> > > example, in CZMQ, the packaging bit would be shipped. That would break
> > > many things in the package build process, and the distro maintainer (ie:
> > > me :-) ) would have to take the shipped tarball and sanitize it, nuking
> > > all extraneous bits. This should not be necessary! That's exactly the
> > > reason "make dist" exists.
> > >
> > > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens  wrote:
> > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
> > luca.bocca...@gmail.com>
> > > wrote:
> > > > >
> > > > >> Is any of the API I marked as draft actually ready for release?
> > > > >
> > > > > Even so, leave it 'draft' until it's actually being used. Changing
> > > > > minds is expensive otherwise.
> > > > >
> > > > >> So should we use branches instead for bugfix releases?
> > > > >
> > > > > All fixes to master. In the extraordinary case where a bugfix release
> > > > > cannot be made from master, a branch could work. We never needed this
> > > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > > > > against branches unless it's the only option. (And I think we've
> > > > > designed ourselves space to never need that option.)
> > > > >
> > > > >> 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.
> > > > >
> > > > > Seems Kevin has solved this, almost :)
> > > > >
> > > > > -Pieter
> > > > ___
> > > > 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
> >
> >
> >
> > ___
> > 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




signature.asc

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

On libzmq master it's now possible to let travis automatically deploy
artifacts. The deployment is triggered if a new tag is created. I've
created a test release and tag[1] to see if it is working properly. The
files that are available under this release have been deploy by travis.

[1] https://github.com/zeromq/libzmq/releases/tag/v4.0.2-test

2016-05-04 11:34 GMT+02:00 Luca Boccassi :

> On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> > Hi,
> >
> > Just for a curiosity - the content of packaging/debian collide with
> > standard Debian packaging? It is intentionally there to not clash, so
> maybe
> > solve this problem. Either by not generating them, either by defying
> safer
> > location.
>
> It's not a problem with the location, it's just that the Debian source
> package will end up having packaging stuff duplicated and with different
> content: 2 changelogs, 2 control files, etc.
>
> But again this is exactly why make dist exists - having that generated
> packaging code in the repository is useful, no need to remove it.
>
> > On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > > One note, 'make dist' always fails the first few times because files
> > > are missing. Keep this in mind. The git tarball has the great
> > > advantage of never failing. (And since it makes tarballs look like git
> > > clones it gives the same experience to all developers.)
> > >
> > > I'd vote for killing 'make dist'. It also makes us dependent on
> autotools.
> >
> > Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> > and ./autogen.sh; ./configure; make dist works just fine.
> > It was broken a while ago, but I fixed it, and now the CI tests that it
> > works.
> >
> > Besides, IMHO there are 2 big problems with just tarring up the git
> > repo.
> >
> > First of all, it doesn't remove the dependency, it just moves it down to
> > the user. Which means we'll start getting bug reports that are due to
> > the different versions of autotools or cmake used (and there are a lot!
> > ).
> >
> > But most importantly, the tarball will ship stuff that shouldn't be
> > shipped, which is a huge problem for distribution packagers. For
> > example, in CZMQ, the packaging bit would be shipped. That would break
> > many things in the package build process, and the distro maintainer (ie:
> > me :-) ) would have to take the shipped tarball and sanitize it, nuking
> > all extraneous bits. This should not be necessary! That's exactly the
> > reason "make dist" exists.
> >
> > > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens  wrote:
> > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
> luca.bocca...@gmail.com>
> > wrote:
> > > >
> > > >> Is any of the API I marked as draft actually ready for release?
> > > >
> > > > Even so, leave it 'draft' until it's actually being used. Changing
> > > > minds is expensive otherwise.
> > > >
> > > >> So should we use branches instead for bugfix releases?
> > > >
> > > > All fixes to master. In the extraordinary case where a bugfix release
> > > > cannot be made from master, a branch could work. We never needed this
> > > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > > > against branches unless it's the only option. (And I think we've
> > > > designed ourselves space to never need that option.)
> > > >
> > > >> 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.
> > > >
> > > > Seems Kevin has solved this, almost :)
> > > >
> > > > -Pieter
> > > ___
> > > 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
>
>
>
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> Hi,
> 
> Just for a curiosity - the content of packaging/debian collide with
> standard Debian packaging? It is intentionally there to not clash, so maybe
> solve this problem. Either by not generating them, either by defying safer
> location.

It's not a problem with the location, it's just that the Debian source
package will end up having packaging stuff duplicated and with different
content: 2 changelogs, 2 control files, etc.

But again this is exactly why make dist exists - having that generated
packaging code in the repository is useful, no need to remove it.

> On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> > One note, 'make dist' always fails the first few times because files
> > are missing. Keep this in mind. The git tarball has the great
> > advantage of never failing. (And since it makes tarballs look like git
> > clones it gives the same experience to all developers.)
> >
> > I'd vote for killing 'make dist'. It also makes us dependent on autotools.
> 
> Uhm I just tried fresh clones of both libzmq and zeromq4-1,
> and ./autogen.sh; ./configure; make dist works just fine.
> It was broken a while ago, but I fixed it, and now the CI tests that it
> works.
> 
> Besides, IMHO there are 2 big problems with just tarring up the git
> repo.
> 
> First of all, it doesn't remove the dependency, it just moves it down to
> the user. Which means we'll start getting bug reports that are due to
> the different versions of autotools or cmake used (and there are a lot!
> ).
> 
> But most importantly, the tarball will ship stuff that shouldn't be
> shipped, which is a huge problem for distribution packagers. For
> example, in CZMQ, the packaging bit would be shipped. That would break
> many things in the package build process, and the distro maintainer (ie:
> me :-) ) would have to take the shipped tarball and sanitize it, nuking
> all extraneous bits. This should not be necessary! That's exactly the
> reason "make dist" exists.
> 
> > On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens  wrote:
> > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi 
> wrote:
> > >
> > >> Is any of the API I marked as draft actually ready for release?
> > >
> > > Even so, leave it 'draft' until it's actually being used. Changing
> > > minds is expensive otherwise.
> > >
> > >> So should we use branches instead for bugfix releases?
> > >
> > > All fixes to master. In the extraordinary case where a bugfix release
> > > cannot be made from master, a branch could work. We never needed this
> > > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > > against branches unless it's the only option. (And I think we've
> > > designed ourselves space to never need that option.)
> > >
> > >> 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.
> > >
> > > Seems Kevin has solved this, almost :)
> > >
> > > -Pieter
> > ___
> > 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




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Michal Vyskocil]

Hi,

Just for a curiosity - the content of packaging/debian collide with
standard Debian packaging? It is intentionally there to not clash, so maybe
solve this problem. Either by not generating them, either by defying safer
location.
On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> One note, 'make dist' always fails the first few times because files
> are missing. Keep this in mind. The git tarball has the great
> advantage of never failing. (And since it makes tarballs look like git
> clones it gives the same experience to all developers.)
>
> I'd vote for killing 'make dist'. It also makes us dependent on autotools.

Uhm I just tried fresh clones of both libzmq and zeromq4-1,
and ./autogen.sh; ./configure; make dist works just fine.
It was broken a while ago, but I fixed it, and now the CI tests that it
works.

Besides, IMHO there are 2 big problems with just tarring up the git
repo.

First of all, it doesn't remove the dependency, it just moves it down to
the user. Which means we'll start getting bug reports that are due to
the different versions of autotools or cmake used (and there are a lot!
).

But most importantly, the tarball will ship stuff that shouldn't be
shipped, which is a huge problem for distribution packagers. For
example, in CZMQ, the packaging bit would be shipped. That would break
many things in the package build process, and the distro maintainer (ie:
me :-) ) would have to take the shipped tarball and sanitize it, nuking
all extraneous bits. This should not be necessary! That's exactly the
reason "make dist" exists.

> On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens  wrote:
> > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi 
wrote:
> >
> >> Is any of the API I marked as draft actually ready for release?
> >
> > Even so, leave it 'draft' until it's actually being used. Changing
> > minds is expensive otherwise.
> >
> >> So should we use branches instead for bugfix releases?
> >
> > All fixes to master. In the extraordinary case where a bugfix release
> > cannot be made from master, a branch could work. We never needed this
> > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > against branches unless it's the only option. (And I think we've
> > designed ourselves space to never need that option.)
> >
> >> 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.
> >
> > Seems Kevin has solved this, almost :)
> >
> > -Pieter
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Ewen McNeill]

On 4/05/16 8:21, Luca Boccassi wrote:

But most importantly, the tarball will ship stuff that shouldn't be
shipped, which is a huge problem for distribution packagers.


To echo this: if there are things in the upstream tarball that they 
shouldn't ship, they have to undo things from the upstream tarball, 
rather than just having some patches adding to it.  In the worst case 
(licensing problems) they have to build a "replacement upstream" 
tarball, which is just painful for everyone.


Personally I think it should be possible for anyone to "make a 
distribution file" (eg, for their own use), and that the tooling to do 
that should be in the repository.  It stops that being magic special 
sauce that is known only to a few people.  Which means "make dist" 
should continue to exist.  (And it sounds like it's been fixed to work, 
which IMHO is the solution to anything that "almost but not quite works" 
:-) )


As for GitHub releases, AFAICT:
- if you tag a release commit, I think you get automagic tar.gz/zip 
releases of what is in the git trees at that commit, which is probably 
useful for distros.  (And some distro systems, eg MacPorts, can also 
clone git as of a release tag and build from that, so it is multi-use.)


- in addition to that, ie, with the tagged release commit, you can 
_also_ upload "binary artefacts" (eg, your own tarballs, or binaries) 
which may have some of the generated bits pre-generated (which removes 
dependencies on some auto tooling/knowledge).  These need to be attached 
to the commit.  AFAICT these bits then get served from Amazon S3 at present.


The combination of these two might give ZeroMQ projects the best of both 
worlds (eg, providing the names didn't conflict).  A "tarball of git" 
_and_ a "ready to build, just run make" version as well, and people 
could get what they wanted.  There's an API for uploading these binary 
artefacts, so it could potentially even come from the CI system (eg, 
Kevin's work with Travis), based on seeing a release tag added.


All of the above depends on having git tags for the release commits.

Also FWIW, Doron and I have been talking about using Amazon S3 
separately to host the existing downloads.zeromq.org tarballs (ie, 
uploaded as binary artefacts).  I think the main thing we'd need is some 
way to translate the (long) S3 URLs into something friendly people can 
find, hosted somewhere.  For which my thought was maybe using 
https://zeromq.github.io/libzmq/ (ie, the gh-pages branch in the 
repository), since that doesn't currently seem to be used, and could be 
auto-built given a list of S3 URLs and the tarballs that were uploaded.


I'd like to get _all_ of downloads.zeromq.org hosted somewhere else this 
month (May 2016) _and_ to ensure that everything that's there (160 
files) are still downloadable (just with new URLs) for posterity.


Ewen

PS: Someone adding release commit tags to the libzmq, etc history for 
all previous releases (ie, as of that commit) would be great.  Or at 
least the recent ones.  But I think that would be a manual process to 
find them (eg, reviewing "git log" looking for changelog updates or 
similar).

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

On Tue, 2016-05-03 at 18:26 +0200, Pieter Hintjens wrote:
> One note, 'make dist' always fails the first few times because files
> are missing. Keep this in mind. The git tarball has the great
> advantage of never failing. (And since it makes tarballs look like git
> clones it gives the same experience to all developers.)
> 
> I'd vote for killing 'make dist'. It also makes us dependent on autotools.

Uhm I just tried fresh clones of both libzmq and zeromq4-1,
and ./autogen.sh; ./configure; make dist works just fine.
It was broken a while ago, but I fixed it, and now the CI tests that it
works.

Besides, IMHO there are 2 big problems with just tarring up the git
repo.

First of all, it doesn't remove the dependency, it just moves it down to
the user. Which means we'll start getting bug reports that are due to
the different versions of autotools or cmake used (and there are a lot!
).

But most importantly, the tarball will ship stuff that shouldn't be
shipped, which is a huge problem for distribution packagers. For
example, in CZMQ, the packaging bit would be shipped. That would break
many things in the package build process, and the distro maintainer (ie:
me :-) ) would have to take the shipped tarball and sanitize it, nuking
all extraneous bits. This should not be necessary! That's exactly the
reason "make dist" exists.

> On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens  wrote:
> > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi  
> > wrote:
> >
> >> Is any of the API I marked as draft actually ready for release?
> >
> > Even so, leave it 'draft' until it's actually being used. Changing
> > minds is expensive otherwise.
> >
> >> So should we use branches instead for bugfix releases?
> >
> > All fixes to master. In the extraordinary case where a bugfix release
> > cannot be made from master, a branch could work. We never needed this
> > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > against branches unless it's the only option. (And I think we've
> > designed ourselves space to never need that option.)
> >
> >> 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.
> >
> > Seems Kevin has solved this, almost :)
> >
> > -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

Wow... :)

On Tue, May 3, 2016 at 7:36 PM, Brian Knox  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 
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Brian Knox]

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 
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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

I'm for not using branches/repository.

This is we do it in NetMQ, all fixes on master + releasing from master.
Much simpler.
On May 3, 2016 19:27, "Pieter Hintjens"  wrote:

> One note, 'make dist' always fails the first few times because files
> are missing. Keep this in mind. The git tarball has the great
> advantage of never failing. (And since it makes tarballs look like git
> clones it gives the same experience to all developers.)
>
> I'd vote for killing 'make dist'. It also makes us dependent on autotools.
>
> On Tue, May 3, 2016 at 6:24 PM, Pieter Hintjens  wrote:
> > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi 
> wrote:
> >
> >> Is any of the API I marked as draft actually ready for release?
> >
> > Even so, leave it 'draft' until it's actually being used. Changing
> > minds is expensive otherwise.
> >
> >> So should we use branches instead for bugfix releases?
> >
> > All fixes to master. In the extraordinary case where a bugfix release
> > cannot be made from master, a branch could work. We never needed this
> > in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
> > against branches unless it's the only option. (And I think we've
> > designed ourselves space to never need that option.)
> >
> >> 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.
> >
> > Seems Kevin has solved this, almost :)
> >
> > -Pieter
> ___
> 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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi  wrote:

> Is any of the API I marked as draft actually ready for release?

Even so, leave it 'draft' until it's actually being used. Changing
minds is expensive otherwise.

> So should we use branches instead for bugfix releases?

All fixes to master. In the extraordinary case where a bugfix release
cannot be made from master, a branch could work. We never needed this
in e.g. CZMQ. I doubt we'd need it in libzmq. I absolutely recommend
against branches unless it's the only option. (And I think we've
designed ourselves space to never need that option.)

> 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.

Seems Kevin has solved this, almost :)

-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

On Tue, 2016-05-03 at 13:26 +0200, Kevin Sapper wrote:
> I'm currently experimenting with travis automated github releases and
> finally gotten to the point where things add up.
> 
> I could try to set this up for libzmq but I need to know how to build the
> release tarballs, checksums, changelog, debs, rpms, etc. Then I can make
> travis upload those artifacts to github releases and even override the
> github generated tarballs.

The release tarball can be built with "make dist".

I don't think we should start releasing debs/rpms. Remember that
debs/rpms are binary releases, which means they MUST be built in the
same environment (libc, etc) as where they are targeted for
installation. This means you can't have one rpm and one deb, you must
have one for each version of each distribution you want to support.

It's a pain, and it's the wrong way to do it. The right way is to make
things easy for the distro maintainers and work with them, so that the
libraries get packaged and distributed from the repositories by the
maintainers.

If someone wants to build and install locally a newer version that it's
available in a distro, make install of the source tarball to /usr/local
tree is safer IMHO.

> 2016-05-03 12:37 GMT+02:00 Pieter Hintjens :
> 
> > The ztools/zmqapi tool generates the 4.2 docs from libzmq master (see
> > apiall script below). The generation tool checks out specific
> > repos/tags for each release, so you can easily set it to generate
> > 4.2.0 from a tagged release.
> >
> > Relevant piece from apiall:
> >
> > #   DirectoryTag  Category
> > $TOOLDIR/apione ../../zeromq3-x  master   3-2
> > $TOOLDIR/apione ../../zeromq4-x  master   4-0
> > $TOOLDIR/apione ../../zeromq4-1  master   4-1
> > $TOOLDIR/apione ../../libzmq master   4-2
> >
> > On Tue, May 3, 2016 at 10:52 AM, Doron Somech  wrote:
> > > Question about the API documentation, now at api.zeromq.org we have
> > docs for
> > > each version coming from the stable branches.
> > >
> > > Should we still have docs for v4.2 separate from master docs? if so where
> > > the v4.2 docs are coming from?
> > >
> > > We can drop the docs per separate versions as we now only have master.
> > >
> > >
> > >
> > > On Tue, May 3, 2016 at 11:39 AM, 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@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
> >
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[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.

:-)

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


signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Kevin Sapper]

I'm currently experimenting with travis automated github releases and
finally gotten to the point where things add up.

I could try to set this up for libzmq but I need to know how to build the
release tarballs, checksums, changelog, debs, rpms, etc. Then I can make
travis upload those artifacts to github releases and even override the
github generated tarballs.

2016-05-03 12:37 GMT+02:00 Pieter Hintjens :

> The ztools/zmqapi tool generates the 4.2 docs from libzmq master (see
> apiall script below). The generation tool checks out specific
> repos/tags for each release, so you can easily set it to generate
> 4.2.0 from a tagged release.
>
> Relevant piece from apiall:
>
> #   DirectoryTag  Category
> $TOOLDIR/apione ../../zeromq3-x  master   3-2
> $TOOLDIR/apione ../../zeromq4-x  master   4-0
> $TOOLDIR/apione ../../zeromq4-1  master   4-1
> $TOOLDIR/apione ../../libzmq master   4-2
>
> On Tue, May 3, 2016 at 10:52 AM, Doron Somech  wrote:
> > Question about the API documentation, now at api.zeromq.org we have
> docs for
> > each version coming from the stable branches.
> >
> > Should we still have docs for v4.2 separate from master docs? if so where
> > the v4.2 docs are coming from?
> >
> > We can drop the docs per separate versions as we now only have master.
> >
> >
> >
> > On Tue, May 3, 2016 at 11:39 AM, 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@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
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Pieter Hintjens]

The ztools/zmqapi tool generates the 4.2 docs from libzmq master (see
apiall script below). The generation tool checks out specific
repos/tags for each release, so you can easily set it to generate
4.2.0 from a tagged release.

Relevant piece from apiall:

#   DirectoryTag  Category
$TOOLDIR/apione ../../zeromq3-x  master   3-2
$TOOLDIR/apione ../../zeromq4-x  master   4-0
$TOOLDIR/apione ../../zeromq4-1  master   4-1
$TOOLDIR/apione ../../libzmq master   4-2

On Tue, May 3, 2016 at 10:52 AM, Doron Somech  wrote:
> Question about the API documentation, now at api.zeromq.org we have docs for
> each version coming from the stable branches.
>
> Should we still have docs for v4.2 separate from master docs? if so where
> the v4.2 docs are coming from?
>
> We can drop the docs per separate versions as we now only have master.
>
>
>
> On Tue, May 3, 2016 at 11:39 AM, 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@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

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Doron Somech]

Question about the API documentation, now at api.zeromq.org we have docs
for each version coming from the stable branches.

Should we still have docs for v4.2 separate from master docs? if so where
the v4.2 docs are coming from?

We can drop the docs per separate versions as we now only have master.



On Tue, May 3, 2016 at 11:39 AM, 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@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