<rant> It seems that, after (or just before) the latest release, version numbers got incremented everywhere.
I thought that we had had a discussion about this in the past and came to some conclusions about when this should happen, but perhaps I imagined it. Library version numbers are important on *NIX systems - they are not just some metadata telling you the release number, they are the version for the ABI. If you increase the library version number then this means that all existing applications need to be recompiled, or they will continue to link against the old version. This means that the major version number should be incremented in these cases: 1) When the layout of a struct that is in a public header changes. 2) When the arguments of a C function change. 3) When a class or method declared in the public headers is removed. 4) When the ivar layout of a class is changed (with the non-fragile ABI, this only applies when an ivar is removed, not when it is moved or when one is added) The minor version should also be incremented in these cases: 1) When a new C function is added. 2) When a new class or method is added to the public headers. 3) With the non-fragile ABI, when an ivar is added. We can only bother incrementing the minor version number for releases, but the major version number should be entirely independent of the release. Subsequent releases that do not break the ABI can and should have the same library version, while ABI changes in svn should result in a major version bump. Ideally, ABI changes should also come with a 'heads up' message to the -dev list, but at the very least they should come with a note in the svn log indicating why the version was bumped. Whoever made the latest change in svn did so without documenting what broke the ABI, and also without making sure that the -gui and -back versions matched, meaning that a clean install of GNUstep will fail because -gui can't find the correct -back version. </rant> David -- Sent from my brain _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
