[zeromq-dev] 0MQ/3.1

[Brian Granger]

I vote option 2 as well.

On Mon, Nov 7, 2011 at 5:11 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Mon, Nov 7, 2011 at 15:17, Pieter Hintjens <ph at imatix.com> wrote:
>>
>> On Tue, Nov 8, 2011 at 1:51 AM, Martin Sustrik <sustrik at 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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com