incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: Version tracking in repo
Date Fri, 07 Mar 2014 14:49:20 GMT
On 3/5/14 3:18 PM, Cory Johns wrote:
> 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.

I was about to write about storing it in a var in Allura/allura/version.py and
bring it into setup.py too (so packaging and other code can access it), but it
looks like we already do that!  But we haven't kept the version number in that
file accurate.  We should do so and put a reminder in our release script steps.

> 
> 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.

By "API version" do you mean the MAJOR part of the version number?  Or something
else?

> 
> 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.

Yeah, I agree.  I think updating the version proactively for api-breaking
changes makes sense, so that we don't forget about those changes.  But most of
the time version can be determined at release time, when reviewing the whole set
of changes.

> 
> Anyway, what are others' thoughts?
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Mime
View raw message