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] Malamute Users - Service Requests API

[Michal Vyskocil]

Hi,

There is nothing like that in malamute broker as far as I know.

You would need to design a custom protocol between client and service to do
so.
Dne 3. 5. 2016 8:04 PM napsal uživatel "Osiris Pedroso" :

> Either that or a heartbeat which would reset the timeout timer.
>
> This would also require an API to confirm that a service request completed
> with success or failure status.
>
> Only then the service request would be removed from requests queue.
>
> If timeout is reached, the request would become active/visible again, and
> delivered to next available worker, since it would now be the oldest
> request still on the queue.
>
> Standard message broker behavior, I tought.
>
> Sent from my iPad. Regularly foiled by autocorrect. But duck it..
>
> On May 3, 2016, at 12:11, Michal Vyskocil 
> wrote:
>
> Hi,
>
> By timeout you mean that client expects an answer for service request in
> $foo seconds?
> Dne 2. 5. 2016 1:15 PM napsal uživatel "Osiris Pedroso" <
> opedr...@gmail.com>:
>
>> Hi,
>>
>> I am new to Malamute and wanted to exchange words with some other user of
>> the Service Requests API in Malamute.
>>
>> Malamute being a message broker, I expected to find some sort of timeout
>> and/or retry logic for in-flight service requests, but from the API I don't
>> think those exist.
>> I wonder how people use the Service Request API to accomplish that.
>>
>> Thanks,
>> Osiris
>>
>> ___
>> 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]

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] Malamute Users - Service Requests API

[Osiris Pedroso]

Either that or a heartbeat which would reset the timeout timer.

This would also require an API to confirm that a service request completed with 
success or failure status.

Only then the service request would be removed from requests queue.

If timeout is reached, the request would become active/visible again, and 
delivered to next available worker, since it would now be the oldest request 
still on the queue.

Standard message broker behavior, I tought.

Sent from my iPad. Regularly foiled by autocorrect. But duck it..

> On May 3, 2016, at 12:11, Michal Vyskocil  wrote:
> 
> Hi,
> 
> By timeout you mean that client expects an answer for service request in $foo 
> seconds?
> 
> Dne 2. 5. 2016 1:15 PM napsal uživatel "Osiris Pedroso" :
>> Hi,
>> 
>> I am new to Malamute and wanted to exchange words with some other user of 
>> the Service Requests API in Malamute.
>> 
>> Malamute being a message broker, I expected to find some sort of timeout 
>> and/or retry logic for in-flight service requests, but from the API I don't 
>> think those exist.
>> I wonder how people use the Service Request API to accomplish that.
>> 
>> Thanks,
>> Osiris
>> 
>> ___
>> 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] Malamute Users - Service Requests API

[Michal Vyskocil]

Hi,

By timeout you mean that client expects an answer for service request in
$foo seconds?
Dne 2. 5. 2016 1:15 PM napsal uživatel "Osiris Pedroso" :

> Hi,
>
> I am new to Malamute and wanted to exchange words with some other user of
> the Service Requests API in Malamute.
>
> Malamute being a message broker, I expected to find some sort of timeout
> and/or retry logic for in-flight service requests, but from the API I don't
> think those exist.
> I wonder how people use the Service Request API to accomplish that.
>
> Thanks,
> Osiris
>
> ___
> 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