<p dir="ltr">IMHO a new build system has nothing to do with it in so far as it is already partially automated.</p>
<p dir="ltr">The real question is when do we update the version (in the html and docs or in a central variable).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Apr 12, 2016 4:26 PM, "Dan Little" <<a href="mailto:theduckylittle@gmail.com">theduckylittle@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote></div>