On Tue, Aug 07, 2012 at 10:15:07AM +0900, Pieter Hintjens wrote: > On Tue, Aug 7, 2012 at 2:40 AM, AJ Lewis <[email protected]> wrote: > > > So the ABI hasn't changed from zeromq 3.0 to 3.2, is that correct? > > The ABI version isn't the same as the product version. It was moved to > 3.0.0 in 0MQ/3.1.0.
Great! > > Typically you'd want to at least rev the last number for every > > release so you could have multiple concurrent versions installed, but > > I don't know how many people actually use that. > > > > This is a good rundown of how it "typically" works, FWIW: > > http://plan99.net/~mike/writing-shared-libraries.html > > It's fun and quite easy to test a hypothesis like "we absolutely need > accurate ABI versioning". > > If no-one makes a pull request with a patch, and takes ownership of > the problem over time, we can be quite confident that the problem > isn't really there, or isn't serious enough to worry anyone. Yeah, unfortunately it's one of those things that's: 1. Not very interesting, so people don't like doing it 2. Not recognized as a problem until it's *really* a problem, and it's quite hard to retroactively fix. It's especially bad because the developer use case for SONAME and .so versioning is quite different from the end-user use case in my experience (developers typically install the latest and greatest, end-users get whatever is given them) but the only ones that know if the .so should get a version bump are the developers. I guess if no end-users are complaining, it's not a current problem, but it's worth thinking about IMHO. -- AJ Lewis Software Engineer Quantum Corporation Work: 651 688-4346 email: [email protected] ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
