Versioning Proposals

Background

• Today Higgins 1.0 is on branch "R1-0-0"
• We have some bug fixes and we have some API changes
• We need to agree on what branches to check them into and what the resulting build is called
• X == incremented any time any Component API changes.
  • Release notes include a summary of API changes and bug fixes.
  • Release notes are nothing but a list of Bugzilla numbers
• Y == incremented for each build that contains no API changes.
  • Release notes include only a summary of bug fixes.
  • Release notes are nothing but a list of Bugtzilla numbers.
• We can independently decide if a new version is just a STABLE build or is a RELEASE build

Proposals...

A

• 1.0.X.Y
• E.g. The first bugfix release after 1.0 would be 1.0.0.1
• E.g. The first API change (e.g. change Node->Entity) after 1.0.0 would be 1.0.1
• E.g. Bugfixes to 1.0.1 would be 1.0.1.1, 1.0.1.2, etc.

B

• 1.X.Y
• E.g. The first bugfix release after 1.0 would be 1.0.1
• E.g. The first API change (e.g. change Node->Entity) after 1.0 would be 1.1
• E.g. Bugfixes to 1.1 would be 1.1.1, 1.1.2, etc.

C

Tom's proposal: A hybrid of A and B.

• We use A for Higgins overall.
• We use B for each Component.

In other words:

• Each release of Higgins after 1.0 is named 1.0.Z
  • Where Z is 1, 2, 3, for each stable or release build
  • E.g. 1.0.1, 1.0.2, etc. are the names of the next few Higgins releases

• Each Eclipse project (e.g. each plugin, each jar, C++ lib) is named 1.X.Y
  • X is incremented for each API or other breaking change
  • Y is incremented for each bugfix
  • E.g. The first bugfix release after 1.0.0 of a component would be 1.0.1
• E.g. The first API change after 1.0.0 (e.g. change Node->Entity) would be 1.1.0