[zeromq-dev] 0MQ/3.1
MinRK
benjaminrk at gmail.com
Tue Nov 8 02:11:04 CET 2011
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111107/fbff1ce5/attachment.htm>
More information about the zeromq-dev
mailing list