VERSIONING RULES This file outlines the rules for versioning the ISSO framework. =============================================================== Final releases have a version number in the form of A.B.C A ----- This is the major version number and should not change unless total API breakage occurs or a major restructuring of the code is done. Currently, the major version is 3 and in the foreseeable future it will remain at this version. B ----- If *any* API changes occur at all this number should be updated. This includes renaming, parameter changes, type changes, or any other change that would affect how an application would interact with the framework. It would not be unreasonable for this number to be relatively high (like 20, or even 100). The logic behind versioning API changes is for compatibility reasons. C ----- The only changes not covered so far by this versioning scheme are bug fixes. ISSO code should be fixed that any minor change (including documentation) or changeset should be placed in its own separate version. Releases should be numerous and fast to ensure that the most recent version is as bug-free as possible. As with the 'B' place, it is acceptable for this number to be very high. All releases should be tagged in git with the proper version number, as well as updating the ISSO_VERSION constant in version.php so applications can check for framework compatibility. Pre-release versions should not be released. Ever. We do not want people building applications with unreleased versions of ISSO, so all tagged and released versions of the framework should be stable and ready for production use. (We already made the mistake of using ISSO3 development code in ViewSVN ... and then it all changed).