"PeiYong PY Zhang" <[EMAIL PROTECTED]> writes: > To reflect the fact that minor version would change the ABI, I > thought it was appropriate to mingle our version(s) no, and that is > why we came up with libxerces-c.so.17.0 (with the soname as > libxerces-c.so.17 ). Thus we shall be free to break ABI in our next > release be it 1.8 or 2.0 or whatever.
Ok, so in effect, you are pretending the release 1.7.0 looks like release 17.0 to linux. > Before this change, the XercesLib was named like > <name>majorversion_minorversion_revision, namely, libxerces-c1_3_0, > libxerces-c1_6_0, and libxerces-c1_6_1, which is > libxerces-c.so.1.3.0 , libxerces-c.so.1.6.0 and libxerces-c.so.1.6.1 > in terms of Linux naming convention. And often, change in revision > implies a bug fix release while change in the minversion implies a > **MAJOR** release, such as new features implemented and most > probably broke the ABI. Ok, this confuses me. If it is a **MAJOR** release when are you changin the minor version number? I would think that you would change the major version number. Currently, the version convention for Xerces is rather arbitrary. What this suggests is the following: * bump MAJOR version when ABI changes * bump MINOR version for significant changes with no ABI change * bump REVISION for minor (bugfix) changes jas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
