Skip to content

Version Numbering System

Lindley Graham edited this page May 15, 2015 · 2 revisions

Based on quickly skimming some sources (http://semver.org/, stackoverflow) we are using major.minor.(revision/patch) (X.Y.Z). The current version number is 0.0.0 (in doc/conf.py and setup.py). based on the sites I referenced we've been technically operating at version 0.1.0. Thus, since we are now adopting a versioning system I will mark the current state of the master branch as version 0.1.0.

The current version is tracked in 3 places: 1. doc/conf.py 2. setup.py 3. a git tag (http://git-scm.com/book/en/v2/Git-Basics-Tagging)

Currently the plan was to switch to version 0.2.0 after the Audit is completed and then version 1.0 by the time the Rocky Mountain UQ Workshop occurs once all the examples have been checked and updated.

I like the guidelines in server.org . TL;DR for our project this means: * If a dev-* branch (or really any branch) is merged into master UPDATE the version number. * ONLY tag the version number on the master branch, use ANNOTATED tags. * If you're working on a dev branch then I don't think it matters much what version is recorded in doc/conf.py or setup.py. I think for now it makes sense to list the version it will be included in when merged into the master branch or the version it originated from, but that's just my opinion. * Update Z for bug fixes * Update Y for backwards compatible functionality updates and backwards changes to the API (reset Z to 0) * Update X for backwards incompatible changes to the API (reset Z and Y to 0)

Clone this wiki locally