I vote option 2 as well. On Mon, Nov 7, 2011 at 5:11 PM, MinRK <[email protected]> wrote: > > > On Mon, Nov 7, 2011 at 15:17, Pieter Hintjens <[email protected]> wrote: >> >> On Tue, Nov 8, 2011 at 1:51 AM, Martin Sustrik <[email protected]> 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. > > If option 1 wins somehow, then I presume that would mean that 3.1 should > undo its removal of LABELs, as > it makes no sense at all to cut the first stable release of 0MQ with labels > *after* deciding they should be removed in the following version. > >> >> 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 2 gets my vote. > I should note that my pyzmq-based app that primarily targets 2.1 had to make > some changes to work with 3.0, and > would have required a major redesign to work with 4.0. It should now > require no further changes to work with 3.1, so it's not all users of 3.0, > only users who picked up the new features that have been put off. > Though I imagine there will be a step backwards in stability, and thus a > delay in the time to the first stable 3.x release, if people are depending > on that schedule. > >> >> 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. > > If it's skipping from 3.0 to 3.1 without ever releasing 3.0 that is of > concern, I see no reason you can't call the new code 3.0.X instead of 3.1.X, > as there still has yet to be a real 3.0 release. There were API-breaking > feature changes between 2.1.0 and 2.1.4, though they were certainly less > significant than this. > -MinRK > >> >> >> >> -Pieter > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
-- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
