Versioning and Release guidelines

This document provides normative way to do releases in project Indus.

  1. Each project should start with a version tag (v0_0).
  2. After each "settled" change to the project, the project can be tagged with date tag.
  3. When the project reaches a state that warrants a new version (minor or major), the project should be tagged with a revision tag (v0_1).
  4. Each time the project enters a release mode for version v0_X, it should be tagged with a revision tag v0_X_preparation.
  5. Each time a project releases software version v0_X, it should be tagged with a revision tag v0_X_release.
  6. The name of every artifact in a release should reflect the revision tag associated with it (module-0.1).
  7. If an older version v0_0 is updated then it is released as module-0.0.1.

According to the above guidelines, all changes pertaining to an upcoming version will be released as enhancement to the current version. So, in case there are breaking API changes, the project should make an initial release of the upcoming version and release the artifacts as part of this new version. This system does not allow for alpha/beta releases. This is intentional.

When solutions to each bug report or feature request, a new tag with the name "bugfix_<bug report number>" or "feature_<feature request number>" should be created upon committing. For example, the fix for bug #768 should be tagged with "bugfix_768".

As for cases where a single commit includes fixes for multiple bug fixes and feature requests, the new tag should be named as "fixes_N" and the tag name should be recorded along with the list of bug report and feature request numbers in the TAGS file in the project. The number N is the next positive integer in the sequence of recorded tags. So, if "fixes_31" is the last tag recorded in TAGS file then the next combined tag will be "fixes_32".

If a bug report or feature request #X is marked as addressed but later on reopened and subsequently addressed, then the tags will be "bugfix_X" and "bugfix_X_1". If the same report is again reopened and addressed then another tag "bugfix_X_2" will be added. If X was previously addressed in a fix with combined tag then the next tag for the fix for X will be "bugfix_X_2". Given the combined tagging can cause confusion, developers are discouraged from using it and addressing the reports individually.