[geomoose-psc] Proper way of incrementing the version in Git?

Dan Little theduckylittle at gmail.com
Tue Apr 12 15:09:02 PDT 2016


The "Makefile" is in the repo and takes in a version.  I say
"Makefile" but it's actually a python script which fires off a bunch
of other processes.

On Tue, Apr 12, 2016 at 5:07 PM, James Klassen <klassen.js at gmail.com> wrote:
> Isn't the makefile in the repo or does the makefile get the version from a
> tag/user input?
>
> On Apr 12, 2016 5:05 PM, "Dan Little" <theduckylittle at gmail.com> wrote:
>>
>> On one of my projects, the "Makefile" takes a version string in and
>> all of the compiled templates/javascript/css get that version placed
>> in the file. The repository does not contain any of the compiled
>> versions of the code.
>>
>> On another, "master" is never used and Dev happens in a different
>> branch at almost all times.  We don't do semantic versioning for that
>> project.  Versions are time based as we release new versions
>> quarterly.
>>
>> On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <klassen.js at gmail.com>
>> wrote:
>> > IMHO a new build system has nothing to do with it in so far as it is
>> > already
>> > partially automated.
>> >
>> > The real question is when do we update the version (in the html and docs
>> > or
>> > in a central variable).
>> >
>> > I think that it would be less confusing if master and the release
>> > branches
>> > are updated in git immediately after the release so that people don't
>> > confuse them as the same as the tagged release.
>> >
>> > The only issue I see is we may not know what the next release should be
>> > called (patch or minor or major update).  Ideally this wouldn't matter
>> > because it would be determined by branch (eg the 2.8 branch can only
>> > have
>> > the next 2.8.x+1 release) while master is always ahead at least a minor.
>> >
>> > On Apr 12, 2016 4:26 PM, "Dan Little" <theduckylittle at gmail.com> wrote:
>> >
>> > Anyone have thoughts on this?
>> >
>> > 1. We drop a version (say 2.8.2).  When doing this the RM ensures that
>> > version is marked properly in the HTML pages.
>> >
>> > 2. We move on to coding new features, bug fixes, etc.
>> >
>> > 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>> >
>> > The "3.0 answer" is "The build system sets the right variables and
>> > it's substituted in the build files". The 2.X answer will probably
>> > remain more human instensive.
>> > _______________________________________________
>> > geomoose-psc mailing list
>> > geomoose-psc at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/geomoose-psc


More information about the geomoose-psc mailing list