On Saturday, 06 October 2007, at 01:50:06 (+0900), Carsten Haitzler wrote: > i know how it works :) i just don't want to work with libtool's > abortion of a versioning system. i want to do it the old fashioned > way. .so major version changes == abi break. old calls removed or > changed abi or functionality. minor version == calls added, but no > functionality changes in existing calls. micro == no calls added or > removed, no functionality changes, just internal fixes/improvements.
That's really how it works already, or at least pretty close. The middle number is micro, so if anything at all changes, you bump the middle number. If you add new API calls, you increment BOTH the first and third number; this will keep the major soversion the same and bump the minor version. If you remove any API calls, set the last number to 0 after incrementing the first number -- this will bump the major soversion. Is that what you were saying? If so, I totally missed it. Too early I guess. :) > i want to keep the version of the package the same as the lib .so > version. it's cleaner and nicer. unless we go screw things up and > decide to name release versions without thought to compatibility - > then we need to do the below, but if we do things right, we don't > need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or > whatever) as opposed to 1.0.0. i will make the package release # the > same as the lib .so version as needed. That will work as long as everyone understands that the *package* version is now a slave to the *library* version, not the other way around. We have to make sure the package is versioned based on the ABI, not just force the soversion to match whatever arbitrary package version we pick. It's nice and clean, that's true -- but it's going to take discipline! > nooo - i don't want to make a new .so for each version with > -release. there is no need to put the link version directly in the > library name. i ONLY need to do this if i plan on having 2 or more > versions of the lib around AND application needing to explicitly > link at compile time to either a newer or older version. eg. gtk2 vs > gtk1. (at that point - mayaswell have new lib names too as the > version is now part of the lib name anyway as far as ld.so etc. are > concerned). Right, but it does give one the ability to use the package version when building the library without breaking soversioning. But if you're wanting to keep them in sync by focusing on the library version, not the package version, that's fine. It's just not the way most projects seem to think these days. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "The world isn't run by weapons any more, or energy, or money. It's run by little 1's and 0's, little bits of data. It's all just electrons! There's a war out there, old friend -- a world war, and it's not about who's got the most bullets. It's about who controls the information: what we see and hear, how we work, what we think. It's all about the information." -- Cosmo (Ben Kingsley), "Sneakers" ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
