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

James Klassen klassen.js at gmail.com
Tue Apr 12 15:07:40 PDT 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20160412/3617c97a/attachment.html>


More information about the geomoose-psc mailing list