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