Bug Fixes and Main Branches
It is useful to understand the structure of the DODS code archives before using CVS to get part of it. The DODS code evolves along a main trunk (we like the tree metaphor). When it is deemed ready for a new release, the evolution is halted, and the new revision of the code is released. However unlikely it seems, there are occasionally bugs in the released code. Evolution of new features continues apace, however, often rendering the development versions of the code incompatible with the released code. As bugs are found, therefore, the bug fixes create a new side branch from the main trunk.
When a new release is ready, the bug fixes applied to the side branches are reviewed to see whether they are relevant to the new code. That is, it is not necessarily true that a particular bug fix will be included in a new release of the DODS software. If a bug appeared in a part of the software that has been extensively changed or deleted, the bug fix that was important for the old released code may be useless for the next revision.
Here's what it looks like:
The revision numbers contain clues to the sort of release
they are. Releases along the main branch are
numbered 2.20, 2.21, 2.22, 3.0 and so on. The
bug-fix releases are numbered starting at the point of
departure: 2.21.1, 2.21.2, 2.21.3, and so on.
When bugs are fixed for the released software, the third part of the version number is incremented. If features are added to the released software, the first or second part is incremented, depending on the scale of the changes. So Version 2.21.3 turns into 2.21.4 if a bug fix is added, but might turn into 2.22 (or 2.22.0) if features are added as well. It might also turn into version 3.0 if enough new features are added.