<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 28, 2013 at 1:16 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I have made a bunch of changes that are all version related.<br>


<br>
1. I have added three functions (not documented)<br>
<br>
pgr_test=# select pgr_version();<br>
 pgr_version<br>
-------------<br>
 2.0.0-dev<br>
(1 row)<br>
<br>
pgr_test=# select pgr_full_version();<br>
               pgr_full_version<br>
------------------------------<u></u>----------------<br>
 2.0.0-dev v2.0dev-271-g6eeef9b sew-devel-2_0<br>
(1 row)<br>
<br>
pgr_test=# select pgr_build_version();<br>
         pgr_build_version<br>
------------------------------<u></u>------<br>
 v2.0dev-271-g6eeef9b sew-devel-2_0<br>
(1 row)<br>
<br>
Here is what all this means:<br>
<br>
2.0.0-dev v2.0dev-271-g6eeef9b sew-devel-2_0<br>
--------- ------- ---  ------- -------------<br>
VERSION   TAG     BUILD HASH   BRANCH<br>
<br>
<br>
2. I have added a top-level file VERSION and tools/pre-commit hook to keep it updated. Daniel you will have to copy tools/pre-commit to .git/hooks/pre-commit<br>
<br>
I'm not sure how much I like this. I have tried a post-commit hook which updates the local file with the hash and build info after the commit in the local copy but not the copy send to github and the pre-commit hook updates the file with the has BEFORE the commit so it always reflects and state before the commit, but that also means the number in the file will match what is on the server.<br>


<br>
BTW, It is not possible to set the hash of a current commit into a file that is getting committed because the hash IS based on the content of the files committed, so you get infinite recursion!<br></blockquote><div><br></div>

<div><br class="">Hi Steve,</div><div><br></div><div>The Git hooks look like a good way to automate this.</div><div>I always thought to use CMake GIT module, but obviously this doesn't work if the source is not a repository.</div>

<div><br></div><div>Looking at PostGIS they also include information about libraries required to build and compile.</div><div>So I thought we could somehow also add information about the version of CMake and Boost for example.</div>

<div>But I don't know exactly how to put this information in SQL files ... probably the Sphinx CMake module does something like this, but I need to study this first.</div><div><br></div><div style>I think the version function is't something that may not change in future versions. So we could leave it like this and we can improve it when we have a good idea.</div>

<div style><br></div><div style>Just one thing I never understood also with the PostGIS version function:</div><div style><ul style><li style>What's the purpose of multiple functions?</li><li style>Why does the return type needs to be a single text string and can't be split into multiple attributes instead? </li>

</ul></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
3. I also modified CMakeLists.txt to read the version info from the VERSION file and commented out the FindGit stuff. This means that if someone grabs a tarball, it will have the VERSION file and cmake will set its variables based on that file which will be more accurate.<br>

</blockquote><div><br></div><div style>This looks more safe.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
4. I have set the pgrouting version number 2.0.0-dev and I have set a tags v2.0dev at approximately the point that I branced sew-devel-2_0 off of master.<br>
<br>
We can remove the pre-commit hook if you don't like that and manually set it at appropriate points in the process, but this makes for errors.<br></blockquote><div><br></div><div style>I think it's good until someone doesn't come with a better idea.</div>

<div style><br></div><div style>For the naming of releases though I would prefer <a href="http://semver.org/">http://semver.org/</a></div><div style><br></div><div style><font face="courier new, monospace">2.0.0-alpha </font></div>

<div style><font face="courier new, monospace">2.0.0-alpha.1 </font></div><div style><font face="courier new, monospace">2.0.0-beta.2 </font></div><div style><font face="courier new, monospace">2.0.0-beta.11</font></div>
<div style>
<font face="courier new, monospace">2.0.0-rc.1</font></div><div style><font face="courier new, monospace">2.0.0</font><br></div><div style><br></div><div style>and if someone wants to add commit information it would be for example</div>

<div style><br></div><div style><font face="courier new, monospace">2.0.0-alpha+g6eeef9b<br></font></div><div><br></div><div style>The question is, if we need to name something "-dev".</div><div style><br></div>

<div style>Daniel</div><div style><br></div><div style><br></div><div style><br></div></div><div><br></div>-- <br><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>

eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>Web: <a href="http://georepublic.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span>
</div></div>