]> src.bluestatic.org Git - isso.git/blob - versioning_rules.txt
e908603ccaeddcb2fdc3cd7f41d8e73cb05fda63
[isso.git] / versioning_rules.txt
1 VERSIONING RULES
2
3 This file outlines the rules for versioning the ISSO framework.
4 ===============================================================
5
6 Final releases have a version number in the form of A.B.C
7
8 A
9 -----
10 This is the major version number and should not change unless total
11 API breakage occurs or a major restructuring of the code is done.
12 Currently, the major version is 3 and in the foreseeable future it
13 will remain at this version.
14
15
16 B
17 -----
18 If *any* API changes occur at all this number should be updated.
19 This includes renaming, parameter changes, type changes, or any other
20 change that would affect how an application would interact with the
21 framework. It would not be unreasonable for this number to be relatively
22 high (like 20, or even 100). The logic behind versioning API changes
23 is for compatibility reasons.
24
25 C
26 -----
27 The only changes not covered so far by this versioning scheme are bug fixes.
28 ISSO code should be fixed that any minor change (including documentation)
29 or changeset should be placed in its own separate version. Releases
30 should be numerous and fast to ensure that the most recent version is
31 as bug-free as possible. As with the 'B' place, it is acceptable for this
32 number to be very high.
33
34 All releases should be tagged in git with the proper version number, as well
35 as updating the ISSO_VERSION constant in version.php so applications can
36 check for framework compatibility.
37
38 Pre-release versions should not be released. Ever. We do not want people
39 building applications with unreleased versions of ISSO, so all tagged
40 and released versions of the framework should be stable and ready for
41 production use. (We already made the mistake of using ISSO3 development
42 code in ViewSVN ... and then it all changed).