Joe Schaefer said: >> Sure they do, when they change the API significantly: SQLite2, Gtk2, >> libxml2. Separate API, manpages, headers, etc. > > Not quite. There's a difference between appending a version number > to library name, and embedding a version number in the function names. > The former is standard practice nowadays because we distribute our C > libraries to other developers, and telling a C compiler which API > you want to compile against can be a royal PITA without > versioning both the soname and INC path. > > The latter is what symbol versioning solves, which works fine when > you're distributing to end-users only. But nobody sane mangles C > function names by actually embedding version numbers in them; the > linker's toolchain is expected to work that out (with a few hints > here and there).
Are you saying that using names like "Apache5::" would be a problem because of calls to class methods? In most cases, the OO interface hides that from users after they use a specific module, but it certainly could get ugly if modules need to call Apache2::Foo->bar() or Apache2_2::Foo->bar(). - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
