I don't think the numbering actually matters (unless you really like the number 3). Numbering seems to be more of a marketing/political issue if it ever does matter. I suspect the topic of breaking backwards compatibility and how to handle it is more important. We will have this when we move from 2.1.x to 3.x already.
We currently have problems in 2 places. The first is in the bindings. This is mitigated a little by the nature of how things are bound, but can be problematic when bindings are deprecated/unsupported and whole new approaches are taken. This requires applications to port their code to the new way if it is different (enums vs constant ints). It may not be much, but it does require people to touch the code which may introduce mistakes (granted, a smart engineer would write a script). The second is in the wire protocol. If the wire protocol changes, how do we have multiple versions of the library in the system. If we don't have any translation mechanism (like a bridge), we would need to stop all the services, update the code and then start up again. If the library talked 2 versions, but preferred the newer, we could stop each device as needed to update to the new version using a rolling restart approach meaning our downtime == 0. Its less of a problem if I have access to all the systems at the same time, but if they are disconnected/different locations - it could be very problematic. Of course, I could also run a complete parallel system for each transition, but suspect that would be costly. Joshua On Jul 18, 2011, at 8:26 AM, Pieter Hintjens wrote: > Hi all, > > A question to the list about release policies[1] and the 3.x development. > > Background: we are removing ZMQ_IDENTITY from the product, it's a > necessary step to continuing to improve the product. (Incidentally, if > you are using ZMQ_IDENTITY, let us know your use case). > > The current release policies require that we start a 4.0 branch to > make this change, since it would break compatibility with 3.0 > applications. > > Does people (and especially binding authors) prefer: > > (a) starting a 4.0 version for this work (which means that 3.x will > stop when 3.0.x is mature) > (b) doing this work in 3.1, and changing the release policies to allow this. > > Thanks > Pieter > > [1] http://www.zeromq.org/docs:policies > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
