[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" <ph at imatix.com> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160503/7e85de69/attachment.htm>