Version numbering of the MusicKit is as follows.
All versions are numbered in the popular standard GNU nomenclature V.R.P, referred here as a version tuple, referring to Version, Revision and Patch respectively. Version refers to major milestones in a project, such as a complete rewrite or major internal conversion, major functional improvement etc. Revision, refers to a minor milestone that can include new functionality that may break external interfacing software, forcing them to be updated (minimally a recompile). Patch, refers to a singular bug fix to correct operation which does not cause an incompatible change or introduce new behaviour.
Each framework has it's own version tuple. This is encoded in the framework and is used by the dynamic loader to verify the correct versions of applications link against the correct versions of frameworks. However, to allow new framework with patches to be installed into operational sites without forcing recompiles of the application, the version tuple encoded in the framework is of the form V.R. Therefore a new patched framework can be installed over the top of the old same numbered framework with the knowledge it will continue to work.
Different software projects adopt different procedures for dealing with branching of the code base. The MusicKit project currently has few branches, however this description is an attempt to define a policy for developers to conform to and to therefore be able to use when retrieving from the Subversion tree. For example, some projects use branches for the “bleeding-edge” or experimental development, with the “head” or “trunk” of the code tree being stable. Successful experiments are then merged back into the head of the main branch of the tree.
The head of the MusicKit can be considered unstable, but should be considered to represent a concensus of development strategies. As explained above, any diverging approaches or experiments will be handled in sub-branch. Likewise, any patches to an existing release other than next impending release will be found in a sub-branch.
This can be counter intuitive. For example, when 5.4.1 is the most recent patch, it is found at the head of the tree. If however, eventually 5.5.0 was released, and then a patch needed to be made to 5.4.1, to be named 5.4.2, this would need to be made in a sub-branch at 5.4.1. In practice, the amount of branching has proven to be nearly zero. If indeed it starts to become necessary to simultaneously support an existing release and an developmental release, this will probably be at the release of a new version (i.e 5.5.0) and we can properly branch there. Comments are welcome!