Great Luca, go ahead. On Jun 16, 2016 22:56, "Kevin Sapper" <kevinsappe...@gmail.com> 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. >> >> 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 <luca.bocca...@gmail.com> >> 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: >> > >> <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 <luca.bocca...@gmail.com>: >> > >> >> > >> > 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! >> > >> > > > > ). >> > >> > > > > >> > >> > > > > 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 < >> p...@imatix.com> >> > >> > 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 >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > 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 >> > > _______________________________________________ > 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
