Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

When appropriate, a working group chairperson requests permission to release these tools and services.  The release manager, at the request of the working group chairperson, are responsible for the release of these tools and services.  Again these independent tools and services are versioned by semantic versioning to indicate what is included with the release (and specifically whether it include includes compatible or non-compatible features and APIs).  Disagreements with a release manager decision about when to release is adjudicated by the TSC.

...

  • When an unforeseen technical challenge arises and the best technical solution as decided by the TSC requires non-backward compatible change (forcing the next version to be a major version vs minor)
  • When, nearing the completion of the release cycle it is discovered that compatibility remains yet it was expected that the release would require a non-compatible change (allowing under some circumstances for the TSC to return to a minor version vs major)
  • When an expected feature associated to with the release is not going to make the release deadline and causes the TSC to re-evaluate the versioning (again more likely going from major to minor)
  • The TSC should not generally make changes to the release/version strategy during the release cycle due to non-technical issues or concerns (example a marketing request to make a major version).  The incorporation of non-technical issues affecting the version decisions should only be taken into consideration during release planning.

...