On Jun 7, 2010, at 2:00 PM, Danny Sung wrote: > I agree. I have no problems with breaking binary&source compatibility > especially if that change will make popt better/easier in the future. But a > change in name seems necessary for app developers to make that choice. eg. > what happens if you're building mulitiple different software packages... both > dynamically linking popt, but one uses 1.x and the other 2.x? The header > files would also need something like #include <popt2/popt2.h> or something > like that. Can't say I particularly like it... but it does those issues > somewhat cleanly. >
I respectfully and strongly _DISAGREE_. The issue can be best be dealt with by using ELF symbol versioning (once I get that it place again in popt-1.17) where a single library can provide _BOTH_ POPT 1.0 and POPT 2.0 functionality _TRANSPARENTLY_ (one the necessary pre-requsite of adding ELF symbol versioning is achieved). If I rename "popt" to "tdod" (or "popt2" that precludes even the attempt at doing better engineering using ELF symbol versioning. While I'm not averse to renaming, I've seen the bleary package churn from libxml -> libxml2 and GNOME 1.0 -> GNOME 2.0. No way Jose! For libraries and projects of XML/GNOME size and magnitude, renaming may have been the only viable way forward. OTOH, popt is _TINY_ and I'm quite prepared for ELF symbol versioning (and I also know that I can figger out whether a pointer is to a POPT 1.0 or a Yet-To-Be-Devised POPT 2.0 table without too much pain. Won't be pretty code, and I am a lazy schmuck maintainer, but I _KNOW_ that I can solve the problem). The only other reason for renaming is to signal developers _EVERYWHERE_ that a change just happened. But that assumes that I am willing to describe the changes ad nauseam for the next couple of years, which is very much not the case. I much prefer "drop-in" transparent "compatibility" and am unwilling to preclude that engineering path by simply wussing out and renaming "popt" to "tdod" (or "popt2" or "getopt106" or ...) which doesn't begin to solve _ANY_ "compatibility" issue at all. In fact, renaming just sanitizes "incompatibility" without solving any problem. > I don't think it's that bad for developers to switch over. Old apps may take > a while. But people will know (especially if you put "#warning popt-1.x is > deprecated" in the headers for 1.x. =) ). And will move new software over. > Look at things like libxml2. > > Ideally, however, popt2 should include mechanisms that allow for future > versions to do this sort of versioning check at runtime. So this popt2 > actually becomes popt ABI 2.0. Not popt-2.0. (eg. popt3 may still use popt2 > ABI.. but then again with all the versioning there may never need to be a > popt3 =) ). > The project name is "POPT", the version being discussed is "2.0". There is no "popt2" nor (imho) is there any need for the renaming, nor setting the precedent of "popt3" -> ... -> "popt123456789" in the 30th century. 73 de Jeff > > On 6/7/2010 9:51 AM, Wayne Davison wrote: >> On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson <n3...@mac.com >> <mailto:n3...@mac.com>> wrote: >> >> The added tyrrany of forcing every application that currently has >> -lpopt >> to change to >> -ljdod >> will be rate-determining to adoption (and glacially/tectonically >> slow imho) >> >> >> For me, if popt 2 is not compatible with popt 1 then I would rather have >> to make a conscious choice to upgrade my code (testing it for >> compatibility), and having to change the libray name as a part of that >> is pretty minor. Having a possibility for my program to be run-time >> linked with a library that is not compatible with what it expects would >> be very bad, imo. >> >> ..wayne.. > > -- > Please note my new email address: da...@dannysung.com > ______________________________________________________________________ > POPT Library http://rpm5.org > Developer Communication List popt-devel@rpm5.org ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
