Hi Pieter- The kernel is in a fairly unique situation: you can only have one installed at a time. (Yes, I know there was some effort to make ZMQ a kernel module.)
For libraries, you can have many different major versions installed at a time, and executables can explicitly link against the one they need. I maintain a library that's ~15yrs old (and on something north of 150,000 machines), and we had full backwards compatibility for 10 years. But at some point, you have to cut the cord, or you spend all your time maintaining multiple version of your API. When you start thinking that breaking changes are off the table, then sub-optimal interfaces become entrenched, and real improvements get sidelined for hacky patches. The path you're suggesting: maintaining those versions within the same codebase (all with a spec of the latest docs), means that you are forced to update them all for every change. Splitting them out into versioned libraries means that you can pick which patches are important (security, stability, etc), and selectively port those back (or forward) to other versions. You will get complaints no matter what you do. Even if you deprecate functions, and give *years* of advance notice (dealt with this recently). But with separation of major versions, users of the lagging versions can stick with older libraries. So they won't be an albatross for changes you'd like to make in newer versions (not to mention adding needless complexity to the API, and needless redundancy to the codebase). Cheers! .timrc ________________________________________ From: zeromq-dev-boun...@lists.zeromq.org [zeromq-dev-boun...@lists.zeromq.org] on behalf of Pieter Hintjens [p...@imatix.com] Sent: Thursday, September 25, 2014 12:05 PM To: ZeroMQ development list Subject: Re: [zeromq-dev] libzmq v4.0.5 The surface API remains simple enough, as we deprecate older calls and remove them from examples and so on. The man pages are quite explicit about marking deprecated API calls. We can be more brutal about removing deprecated code, though I've not seen anyone raise an issue with the current situation. Removing deprecated pieces will certainly cause complaints. This is really basic. A version bump does NOT excuse breakage. I don't know how to keep explaining this in different ways. Let me quote Linus Torvalds: "DON'T BREAK EFFING USER SPACE" or something like that. Even a ZeroMQ v5.0 would have to support 3.2 and 2.0 API calls (which can be taken out of the man pages) unless there is a real, significant benefit in removing them. -Pieter On Thu, Sep 25, 2014 at 8:26 PM, Tim Crowder <crowd...@yahoo-inc.com> wrote: > Complaints are not the only (or best) measure of quality. > How many questions does the multitude of semi-redundant functions generate on > this list, > especially from new users trying to get started? (More so, since some > functions take void* > and so can't validate by argument type). > > Perhaps it's time for a major version bump with some consolidation... > > Cheers! > > .timrc > ________________________________________ > From: zeromq-dev-boun...@lists.zeromq.org > [zeromq-dev-boun...@lists.zeromq.org] on behalf of Pieter Hintjens > [p...@imatix.com] > Sent: Thursday, September 25, 2014 5:20 AM > To: ZeroMQ development list > Subject: Re: [zeromq-dev] libzmq v4.0.5 > > On Thu, Sep 25, 2014 at 1:39 PM, Goswin von Brederlow <goswin-...@web.de> > wrote: > >> That is fine for major changes where a completly new function makes >> sense. But not for minor behaviour changes that only conern corner >> cases. It doesn't make sense to end up with 20 zmq_sock() like >> functions that all return a slightly differently behaving socket. > > We've already done this, and no-one complains: > > - zmq_send > - zmq_sendmsg > - zmq_msg_send > - zmsg_send > - zstr_send > - zframe_send > - zsock_send > - zactor_send > > All do kind of the same thing. The only time people complained > (rightly) was when 3.0 changed zmq_send. > > In practice you don't get 20 variations. You get 2 or 3, one for each > stable generation. Remember we can change draft APIs at will. We make > a stable release maybe once a year. We save old APIs for a few > generations, then delete them. > >> HTTP does do exactly that. When you connect you say: >> >> GET /index.html HTTP/1.1 > > Yes, except it's used for almost nothing significant, and there was > never a successful 1.2 or 2.0. That kind of proves my point. (I've > written many complete HTTP server stacks.) > >> Which is fine if you follow your own contract. Zeromq has broken it 3 >> times now so that isn't the best track record. > > Indeed. However this isn't my project, it's *our* project and we all > enforce the rules, or we don't. My job has been to define workable > rules. I'll enforce them on aspects of the project I use and thus care > about. > > Anyone using those pieces that got broken had the tools to stop that > happening, and didn't say anything. We can investigate why, and fix > that, if someone cares. > >> And there are a number >> of things I would like to change eventually. Like ZMQ_STREAM sockets >> shouldn't require the MORE flag for every frame, alternating between >> destination and data frames. Instead they should work like ROUTER >> sockets and take the first frame of a multi-part message as the >> destination address and send the rest onwards. > > Indeed. You can already do this in several ways. You don't need to > expose ABI versions for this. Indeed we have a good, existing > mechanism for feature updates to socket types. Check the many ROUTER > socket options. > >> That I think is the advantage of the FUSE solution. By defining a >> higher FUSE_USE_VERSION you can not only get new features enabled but >> also deprecated features removed. > > OK, I do accept the problem statement of multiple versions of an API. > > There are many solutions. Remember our focus is distributed software > and a distributed community. This is important. It means we work on > many pieces at the same time, and they evolve independently over a > long time, and at a distance. > > What this means is that we do not have a single API contract stream. > Yes, you can say "this is version X" however you cannot use the version > number as a mechanism for changing semantics. > > Here's the proof: you have piece A and now someone wants to change that > to A'. New version number. Now, user can choose between A and A' using > the version number. However now we want to improve A and make A''. This > is not an improvement of A'. How does this work? New version again? > > We've effectively forced an internal fork of the code. Now multiply > this by the number of aspects we play with. > > This is why I called it "insane". > > The sane and simple solution, which we use and which is proven, is to > use different namespaces that can evolve independently, and never break > existing code. > > This is how we have lots of socket options, how we have many CZMQ classes, > and so on, and how this all works with many old versions and in a real > distributed community, without version madness or internal confusion. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
