[pgrouting-dev] Version, version, who has the version

[Daniel Kastl]

On Tue, May 28, 2013 at 10:00 PM, Stephen Woodbridge <
woodbri at swoodbridge.com> wrote:

> On 5/28/2013 12:45 AM, Daniel Kastl wrote:
>
>>
>>
>>
>> On Tue, May 28, 2013 at 1:16 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.**com<woodbri at swoodbridge.com>>>
>> wrote:
>>
>>     I have made a bunch of changes that are all version related.
>>
>>     1. I have added three functions (not documented)
>>
>>     pgr_test=# select pgr_version();
>>       pgr_version
>>     -------------
>>       2.0.0-dev
>>     (1 row)
>>
>>     pgr_test=# select pgr_full_version();
>>                     pgr_full_version
>>     ------------------------------**__----------------
>>
>>       2.0.0-dev v2.0dev-271-g6eeef9b sew-devel-2_0
>>     (1 row)
>>
>>     pgr_test=# select pgr_build_version();
>>               pgr_build_version
>>     ------------------------------**__------
>>
>>       v2.0dev-271-g6eeef9b sew-devel-2_0
>>     (1 row)
>>
>>     Here is what all this means:
>>
>>     2.0.0-dev v2.0dev-271-g6eeef9b sew-devel-2_0
>>     --------- ------- ---  ------- -------------
>>     VERSION   TAG     BUILD HASH   BRANCH
>>
>>
>>     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
>>
>>     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.
>>
>>     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!
>>
>>
>>
>> Hi Steve,
>>
>> The Git hooks look like a good way to automate this.
>> I always thought to use CMake GIT module, but obviously this doesn't
>> work if the source is not a repository.
>>
>> Looking at PostGIS they also include information about libraries
>> required to build and compile.
>> So I thought we could somehow also add information about the version of
>> CMake and Boost for example.
>> 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.
>>
>
> OK, I do not think that we need to add the library information. In the
> postGIS case, there code and therefore their bugs, are highly related to
> their libraries and they also develop, support and release some of the
> libraries. The only library that we are dependent on at the moment is CGAL
> and I don't expect that we will have many bugs because of this dependency.
> So lets not do this.
>
> Regarding how the names get into the pgr_*version() functions the SQL just
> have cmake variable names and in CMakeLists.txt we have:
>
> configure_file("${CMAKE_**BINARY_DIR}/lib/pgrouting--${**
> PGROUTING_VERSION_STRING}.sql.**in <http://sql.in>"
>     "${CMAKE_BINARY_DIR}/lib/**pgrouting--${PGROUTING_**
> VERSION_STRING}.sql")
>
> that does the subsitution. You can do the same thing with doc files if you
> have cmake pre-process them, do it how you are doing it now.
>
>  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.
>>
>> Just one thing I never understood also with the PostGIS version function:
>>
>>   * What's the purpose of multiple functions?
>>   * Why does the return type needs to be a single text string and can't
>>
>>     be split into multiple attributes instead?
>>
>
> It is just easier to use the function that you gives you what you need
> rather than require the user to figure out how to parse the strings. We
> already know how to do that, but everyone might not.
>
>
Hi Steve,

What about just one "pgr_version()" function?
I don't get the use case where we need two of them ;-)

I think "pgr_version()" should then return the "full" version.

Daniel






-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130529/6ea9d2d0/attachment.html>