Hi, As a (mostly) silent watcher of this mailing list I really have the impression than beyond tests or experimentation the 3.0 branch is not really used which would not be that surprinsing for a beta version.
I want to put zeromq to use but did not get a good chance to do it for now. Option 2 take my vote. On 8 November 2011 01:04, Phil Stanhope <stanh...@gmail.com> wrote: > i have nothing in production ... but would want a path from 2.1 to 3.1 and > predictable path (to the extent possible) going forward. > > So ... option 2. > > > On Tue, Nov 8, 2011 at 7:51 AM, Joshua Foster <jhaw...@gmail.com> wrote: > >> Option 2. I never really got far enough with 3.0 since I couldn't see a >> forward path from 2.1 to 3.0 to 4.0. >> >> Joshua >> >> On Nov 7, 2011, at 6:17 PM, Pieter Hintjens wrote: >> >> > On Tue, Nov 8, 2011 at 1:51 AM, Martin Sustrik <sust...@250bpm.com> >> wrote: >> > >> >> It's up to Pieter whether he wants to maintain 3-0 further. >> >> Pieter, what do you think? >> > >> > /me was expecting this to bounce back to me. I'm going to bounce this >> > back to the community since the only rationale for maintaining a >> > version is that there are people who need that version. >> > >> > So let's take a vote. These are the options I can see, please choose >> > one and argue / vent as you like: >> > >> > Option 1: maintain 3.0 through to stable, eventually deprecate 2.1 and >> > then start packaging 3.1 as alpha. Pros: it's consistent and gives the >> > impression we know what we're doing. Cons: it's insane because 3.1 >> > speaks its own wire protocol incompatible with previous and following >> > versions. >> > >> > Option 2: deprecate 3.0 now, and start packaging 3.1 as alpha. Since >> > it's wire compatible with 2.1, people can test it immediately and we >> > should be able to push it through to maturity rapidly. Pros: simplest. >> > Cons: anyone using 3.0 in real life is kind of screwed. >> > >> > Option 3: remove labels from 3.0 and make it wire-compatible with 2.1 >> > and 3.1. Continue with current release planning. Pros: gives us the >> > release story we should have had from the start IMO. Cons: not sure if >> > it's even possible. >> > >> > -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
