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

[Jim Klassen]

The update should probably go here [1] (which also documents how things
are being built on the demo server).

[1] http://www.geomoose.org/developer/release.html

On 04/13/2016 10:09 AM, Dan Little wrote:
> As much as I loathe unnecessary commits (and SVN carry over I think)
> it's probably good for us to do a "change version commit" then
> "release commit" then "change version to  something indicating dev
> commit".
>
> Should this be made an RFC? An RFC addendum/clarifier? Or something we
> just "know Jim does"?
>
> On Tue, Apr 12, 2016 at 11:37 PM, Eli Adam <eadam at co.lincoln.or.us> wrote:
>> We have some details (accumulated by mostly noticing things we
>> forgot), http://geomoose.org/developer/release.html
>>
>> Trunk could always be some clearly non-release number, 2.x, 2.#,
>> 2-dev, etc.  And numbers only get assigned in releases when they
>> happen.
>>
>> I think that GDAL added a future/fake date to trunk after repeated
>> confusion of whether it had been released or not, "GDAL 2.1.0dev,
>> released 2015/99/99"
>>
>> Eli
>>
>> On Tue, Apr 12, 2016 at 5:15 PM, James Klassen <klassen.js at gmail.com> wrote:
>>> Ok
>>>
>>> On Apr 12, 2016 5:09 PM, "Dan Little" <theduckylittle at gmail.com> wrote:
>>>> 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
>>>
>>> _______________________________________________
>>> geomoose-psc mailing list
>>> geomoose-psc at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc