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

[Eli Adam]

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