incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <john...@gmail.com>
Subject Version tracking in repo
Date Wed, 05 Mar 2014 20:18:07 GMT
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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message