Apache Directory Project Management > Index > Version Numbering Scheme
Added by Alex Karasulu, last edited by Ersin Er on Oct 29, 2006  (view change)

Introduction

A 3 point numbering scheme is used for versioning:

  [directory:major].[directory:minor].[directory:micro]

Major Number

The major number represents significant differences between software releases. Changes in the major version represent incompatible changes in architecture, platform or API. A complete rewrite or redesign may bump the major version number.

A change to discontinue support for a specific platform may also trigger a bump in the major version number.

Some consider bumping the minor number several notches from say a 1.0 to a 1.5 for example to connotate a change in platform like switching from JDK 1.4 to JDK 5.0. This is also an acceptable tactic to employ.

Minor Number

Minor numbers are used to connotate changes to features and APIs in the product with minor changes which may or may not introduce compatibility issues. The compatibility issues are not severe ones where dependent applications must completely rewrite junctions using/integrating the product.

Furthermore odd minor numbers connotate unstable developmental releases to introduce new features to the community. Even numbered minor numbers are for stable product releases which are recommended for use in production.

Minor numbers usually correspond to separate branches of development on the same code base.

Micro Number

If the minor number is odd, the micro number represents new feature additions in a development release from a feature branch. Bugs may be fixed from previous releases or they may not with only simple feature introductions. There is no quality assurance taking place here. Only new features are being introduced with the chance that bug fixes are also occuring.

If the minor number is even, the micro number represents ONLY bug fixes in a production release of a stable branch. No new features are being added and absolutely no API changes are being made. The only thing other than bug fixes which can go into these micro releases of stable branches are performance optimizations.

Using Release Candidate (RC) Designators

At some point developers will decide to freeze the introduction of new features and focus on stabilizing the software. At such a point in time a new stable branch may be created with an even version number. For example in a 1.3 branch developers might decide it's time to freeze features and start stabilizing the product for a 1.4 release.

At these boundries between a development branch (odd minor number) and a stable branch (even minor number) developers might not want to immediately release 1.4 without making some release candidates available to the public to test. Here the RC designator can be used to tell users that this is a feature frozen release for testing and not a true production grade release.

All successive RCs will try to irradicate known bugs in the software. Once a RC is deemed stable the production ready release can be made using an even minor number (1.4.0 in the example above). Between RC releases only bug fixes or optimizations should be made without changes to the API. You're trying to stabilize the software for production and don't want to make changes that may destabilize the product or change the expectation of users. In this stage users can start using the product with a guarantee that interfaces will not change but glitches will be fixed so they can incorporate the product into their beta offerings.

Handling Unusual Circumstances

Sometimes big changes in architecture or a complete rewrite bump up the major version number. If immediately after these changes the community wishes to feature freeze development and come out with a new major version number then they can stablize the release using release candidates of the new major version with minor number 0.

At other times major number bumps may be required but the community still plans on adding new features in subsequent releases so the new major revision with minor number of 0 cannot connotate a stable release.

In these cases the change in the major number can also jump to an odd minor number. Say ApacheDS is rewritten entirely at some point when it's highest released version at 5.6.4. The newly released technology preview may be released as a 6.1.0 to denote it's instability and the fact that more features will continue to be added.