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).