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

[Dan Little]

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