Version Numbering
Fonty Python follows the standard triplet version numbering scheme:
Major.Minor.Revision
- Major
- changes indicate substantial improvements in functionality, changes in architecture, or major adjustments in dependencies
- Minor
- changes indicate new functionality or design that do not warrant a new major version number. Every effort should be taken to ensure that minor versions do not change requirements/dependencies for end-users.
- Revision
- changes indicate bug fix or patch releases
Pre-release naming
Before major and minor releases, the development team may choose to release beta and release candidate versions to allow for bug fixing and minor adjustments. Such releases will be indicated by -bX or -rcX endings.
Pre-1.0
Note that Fonty Python has not reached a 1.0 release yet, and 0.x releases should not be expected to maintain consistent program dependencies, function/variable naming, and architecture the way minor releases in the 1.x series (and beyond) will.
Issues with this scheme to discuss
- How to make sure that development discussion can point to a stable version number when discuss new features and changes.
- This was a problem with the Drupal project's use of this scheme... no one could ever be sure whether the next version was going to be 4.8 or 5.0, and so there was a lot of inconsistency and confusion during discussion of new versions. It was also unclear when it was appropriate to increment the major version number.
- Drupal has now changed to a dual version numbering scheme (Version.Revision) where Version increments indicate that there is new functionality and, probably, API and other such changes, and the Revision number indicates bug fix and patch releases. This is nice becuase they always know that the next release after 5.x is 6.x, and no one has to have big debates about whether the next version is a major one or a minor one.
- I imagine that Fonty Python will probably want to make more releases, though. A minor version number better supports a "release often, release early" model where we can get new functions that people want/need out the door faster. Without it, there would be some hand-wringing about whether that small functionality improvement really warrants a new major version. The problem is, I really do hate the confusion of moving target version numbers.
- Related to this, many projects arbitrarily increase the value of the minor version number based on how different they think their release is from the previous one. This is a good indicator for users of the amount of change, but introduces the moving target version number issue from another vector. We should make a decision about whether to always increment by 1, or to make those decisions elsewhere.
- Re beta and release candidates. I love them as a user and hate them as a developer. As a developer, especially in OSS, it's nice to be able to get a release out the door without being overly concerned about stability. Of course, testing should be rigorous, but it's nice not to have to worry that we've ferreted out every single bug before we feel comfortable marking a release without a beta or rc tag. From a end-user perspective, it's always useful to be able to see just exactly how stable a code base I am running is supposed to be. Maybe there is a way to use a number to indicate the level of testing?
