I'd like to propose, and request feedback for, an idea for tracking the version number for Allura.
I think we've pretty well settled on using semantic versioning (see: semver.org), which requires the MAJOR version number to be increased whenever an "incompatible API change." As it might not always be obvious from the ticket or commit log whether an incompatible change has been made, I propose that we start tracking at least part of the version number in the repository itself, e.g., in a VERSION file. This way, it will be obvious when the MAJOR version number must change, as it can be updated along with the code change that necessitates it. Since we likely don't want to increase the version number with each commit (or do we?), we could instead track the "API version" in the repository, and only update the MINOR and PATCH versions upon release, external to the code itself. Alternatively, we could track both the MAJOR and MINOR version numbers in the repository, which would require us to update the MINOR version number for (and resolve conflicts between) each ticket that adds a new, backwards compatible feature. This would take all of the guesswork / judgement out of determining the release version. However, I think that Allura is still proceeding with a sufficient amount of feature development that doing it this way would cause more conflict on the version number than would be worth the benefit. Anyway, what are others' thoughts?
