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: > <constraints>). > 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 <[email protected]>: > > > 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 <[email protected]>: > > > > > > > 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 <[email protected]> > > wrote: > > > > > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi < > > > > [email protected]> > > > > > 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 > > > > > > [email protected] > > > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > > > > > > _______________________________________________ > > > > > zeromq-dev mailing list > > > > > [email protected] > > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > _______________________________________________ > > > > > zeromq-dev mailing list > > > > > [email protected] > > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > zeromq-dev mailing list > > > > [email protected] > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > _______________________________________________ > > > zeromq-dev mailing list > > > [email protected] > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
