On Mon, Nov 7, 2011 at 15:17, Pieter Hintjens <p...@imatix.com> 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. > 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 zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
