Software versioning: outline

This entry is a bliki, a personal blog entry that I'll update wiki-style.

I'd like to address software versioning, as well as the use of stable and development branches.

I'll update this page over time. Here is a rough outline of what I wish to address:

- version x.y.suffix for most software:
x is the feature branch.
.y is the release version.
.suffix describe development stage. 'suffix' is one of 'alpha', 'beta', 'rc', 'stable', 'unmaintained' (for a final release in an obsoleted branch).

- version z.x.y.suffix, for libraries.
z is the ABI compatibility branch.

- There may be a prefix like prefix.x.y.suffix for software which very heavily depend on a major upstream library, like qt4.x.y.suffix, qt5.x.y.suffix, kd5.x.y.suffix. Although I'm not sure it's necessary. A simple documentation table would achieve the same result, without overly complicating the versioning.

- stable branches must be maintained for at least 2 years.
- stable branches must be maintained for at least 1 year after the feature branch above it has reached stable stage.
- all bug fixes applied to any development branch must also be applied (back-ported) to maintained stable branches.
- all new features can only be applied to a new development branch which is in .alpha or possibly .beta stage.

- There is no special significance to version 1.0. On the contrary, being a .0 release, it means that it is the first release of a new branch, including new features. As such the suffix must be .alpha: 1.0.alpha.

- Maintainers are encouraged to rapidly release a working version with limited features. Stabilize the software by working on bugs and critical issues (e.g. data loss) first.
- Do not let bugs accumulate.
- Do not fix bugs in the latest development branch only.
- Fix bugs by re-factoring the code, if necessary.