[zeromq-dev] ZeroMQ 4.2 release, planning

Kevin Sapper kevinsapper88 at gmail.com
Mon May 9 11:45:28 CEST 2016


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.boccassi at 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 <ph at imatix.com> wrote:
> > > > On Tue, May 3, 2016 at 2:12 PM, Luca Boccassi <
> luca.boccassi at 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 at lists.zeromq.org
> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160509/5e971532/attachment.htm>


More information about the zeromq-dev mailing list