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

pgRouting pgrouting-dev
1

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!

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.

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.

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.

-Steve

2

On Tue, May 28, 2013 at 1:16 PM, Stephen Woodbridge <woodbri@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.

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?

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.

This looks more safe.

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.

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.

I think it's good until someone doesn't come with a better idea.

For the naming of releases though I would prefer http://semver.org/

2.0.0-alpha
2.0.0-alpha.1
2.0.0-beta.2
2.0.0-beta.11
2.0.0-rc.1
2.0.0

and if someone wants to add commit information it would be for example

2.0.0-alpha+g6eeef9b

The question is, if we need to name something "-dev".

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

3

On 5/28/2013 12:45 AM, Daniel Kastl wrote:

On Tue, May 28, 2013 at 1:16 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@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"
     "${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.

    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.

This looks more safe.

    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.

    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.

I think it's good until someone doesn't come with a better idea.

For the naming of releases though I would prefer http://semver.org/

2.0.0-alpha
2.0.0-alpha.1
2.0.0-beta.2
2.0.0-beta.11
2.0.0-rc.1
2.0.0

and if someone wants to add commit information it would be for example

2.0.0-alpha+g6eeef9b

The question is, if we need to name something "-dev".

Yes, -dev is all the time from the last release until your get to alpha. We have done over 270 builds(commits) since I tagged this branch.

-Steve

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

4

On Tue, May 28, 2013 at 10:00 PM, Stephen Woodbridge <
woodbri@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@swoodbridge.com <mailto:woodbri@swoodbridge.**com<woodbri@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 :wink:

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

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

5

On 5/28/2013 10:14 PM, Daniel Kastl wrote:

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

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

I'm fine with have to two functions.

pgr_full_version() - this would be the full string with everything
pgr_version() - this should match version of extension like:
                       2.0.0-dev in pgrouting--2.0.0-dev.sql

The full version string is what we want for bug reporting.
The version is what you might want to use in an application to construct if clauses based on features available in this or that version of the software.

This seems simple and convenient to provide and is a straight forward explanation of what they are for.

-Steve

6

On Wed, May 29, 2013 at 12:18 PM, Stephen Woodbridge <
woodbri@swoodbridge.com> wrote:

On 5/28/2013 10:14 PM, Daniel Kastl wrote:

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

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

I'm fine with have to two functions.

pgr_full_version() - this would be the full string with everything
pgr_version() - this should match version of extension like:
                      2.0.0-dev in pgrouting--2.0.0-dev.sql

The full version string is what we want for bug reporting.
The version is what you might want to use in an application to construct
if clauses based on features available in this or that version of the
software.

What about

pgr_version() -> should match version of extension
pgr_version("full") -> full string with everything (could be also "debug")

I know this is not really important discussion, but we did so well in
decreasing the number of functions and then we're having multiple ones for
just getting the version information :wink:
Also I had to add two pages to the function reference somehow.

I still like the idea to return a record, because someone could pick what
is important if used for an application, like:

SELECT * FROM pgr_version();

version | tag | build | hash | branch
----------+---------+-------+----------+---------------
2.0.0-dev | v2.0dev | 271 | g6eeef9b | sew-devel-2_0

So one could get the version with SELECT version FROM pgr_version() in case
they really use it for some application for example;

Well, I think I can do the modification as well.

Daniel

This seems simple and convenient to provide and is a straight forward
explanation of what they are for.

-Steve

______________________________**_________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev&lt;http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

7

On 5/28/2013 11:40 PM, Daniel Kastl wrote:

On Wed, May 29, 2013 at 12:18 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    On 5/28/2013 10:14 PM, Daniel Kastl wrote:

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

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

    I'm fine with have to two functions.

    pgr_full_version() - this would be the full string with everything
    pgr_version() - this should match version of extension like:
                           2.0.0-dev in pgrouting--2.0.0-dev.sql

    The full version string is what we want for bug reporting.
    The version is what you might want to use in an application to
    construct if clauses based on features available in this or that
    version of the software.

What about

pgr_version() -> should match version of extension
pgr_version("full") -> full string with everything (could be also "debug")

I know this is not really important discussion, but we did so well in
decreasing the number of functions and then we're having multiple ones
for just getting the version information :wink:
Also I had to add two pages to the function reference somehow.

I still like the idea to return a record, because someone could pick
what is important if used for an application, like:

SELECT * FROM pgr_version();

version | tag | build | hash | branch
----------+---------+-------+----------+---------------
2.0.0-dev | v2.0dev | 271 | g6eeef9b | sew-devel-2_0

So one could get the version with SELECT version FROM pgr_version() in
case they really use it for some application for example;

This would require defining a new TYPE, I suppose I we could return text then you could use array_to_string() to concat them with hyphens.

I don't like the idea of passing arguments to get different strings, because I have not seen it on any other apps.

I would just have leave it as two functions and put them both on one doc page. Or if you want it parsed return a text array. I'm happy to make the changes that is trivial.

-Steve

Well, I think I can do the modification as well.

Daniel

    This seems simple and convenient to provide and is a straight
    forward explanation of what they are for.

    -Steve

    _________________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/__mailman/listinfo/pgrouting-dev
    <http://lists.osgeo.org/mailman/listinfo/pgrouting-dev&gt;

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

8

On Wed, May 29, 2013 at 12:53 PM, Stephen Woodbridge <
woodbri@swoodbridge.com> wrote:

On 5/28/2013 11:40 PM, Daniel Kastl wrote:

On Wed, May 29, 2013 at 12:18 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.**com<woodbri@swoodbridge.com>>>
wrote:

    On 5/28/2013 10:14 PM, Daniel Kastl wrote:

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

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

    I'm fine with have to two functions.

    pgr_full_version() - this would be the full string with everything
    pgr_version() - this should match version of extension like:
                           2.0.0-dev in pgrouting--2.0.0-dev.sql

    The full version string is what we want for bug reporting.
    The version is what you might want to use in an application to
    construct if clauses based on features available in this or that
    version of the software.

What about

pgr_version() -> should match version of extension
pgr_version("full") -> full string with everything (could be also
"debug")

I know this is not really important discussion, but we did so well in
decreasing the number of functions and then we're having multiple ones
for just getting the version information :wink:
Also I had to add two pages to the function reference somehow.

I still like the idea to return a record, because someone could pick
what is important if used for an application, like:

SELECT * FROM pgr_version();

version | tag | build | hash | branch
----------+---------+-------+-**---------+---------------
2.0.0-dev | v2.0dev | 271 | g6eeef9b | sew-devel-2_0

So one could get the version with SELECT version FROM pgr_version() in
case they really use it for some application for example;

This would require defining a new TYPE, I suppose I we could return text
then you could use array_to_string() to concat them with hyphens.

I don't like the idea of passing arguments to get different strings,
because I have not seen it on any other apps.

Me neither. I would prefer to query for attributes as well.

I would just have leave it as two functions and put them both on one doc
page. Or if you want it parsed return a text array. I'm happy to make the
changes that is trivial.

Do you really need to define new types to return a table?

I just did it like this in another function variant:
https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_network_check.sql

I didn't have to create a type for that.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

9

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!

How do you manage to get the updated VERSION file to be part of the last
commit?
I added the pre-commit file as you said, but every time I commit, the
VERSION file changes and is marked as modified. And on the Github
repository I'm theoretically always one commit hash behind.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

10

On Wed, May 29, 2013 at 1:17 PM, Daniel Kastl <daniel@georepublic.de> wrote:

On Wed, May 29, 2013 at 12:53 PM, Stephen Woodbridge <
woodbri@swoodbridge.com> wrote:

On 5/28/2013 11:40 PM, Daniel Kastl wrote:

On Wed, May 29, 2013 at 12:18 PM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.**com<woodbri@swoodbridge.com>>>
wrote:

    On 5/28/2013 10:14 PM, Daniel Kastl wrote:

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

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

    I'm fine with have to two functions.

    pgr_full_version() - this would be the full string with everything
    pgr_version() - this should match version of extension like:
                           2.0.0-dev in pgrouting--2.0.0-dev.sql

    The full version string is what we want for bug reporting.
    The version is what you might want to use in an application to
    construct if clauses based on features available in this or that
    version of the software.

What about

pgr_version() -> should match version of extension
pgr_version("full") -> full string with everything (could be also
"debug")

I know this is not really important discussion, but we did so well in
decreasing the number of functions and then we're having multiple ones
for just getting the version information :wink:
Also I had to add two pages to the function reference somehow.

I still like the idea to return a record, because someone could pick
what is important if used for an application, like:

SELECT * FROM pgr_version();

version | tag | build | hash | branch
----------+---------+-------+-**---------+---------------
2.0.0-dev | v2.0dev | 271 | g6eeef9b | sew-devel-2_0

So one could get the version with SELECT version FROM pgr_version() in
case they really use it for some application for example;

This would require defining a new TYPE, I suppose I we could return
text then you could use array_to_string() to concat them with hyphens.

I don't like the idea of passing arguments to get different strings,
because I have not seen it on any other apps.

Me neither. I would prefer to query for attributes as well.

I would just have leave it as two functions and put them both on one doc
page. Or if you want it parsed return a text array. I'm happy to make the
changes that is trivial.

Do you really need to define new types to return a table?

I just did it like this in another function variant:

https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_network_check.sql

I didn't have to create a type for that.

I tried this and it works pretty well:

CREATE OR REPLACE FUNCTION public.pgr_version()
  RETURNS TABLE(
"version" varchar,
tag varchar,
build varchar,
hash varchar,
branch varchar
) AS
$BODY$
DECLARE

BEGIN
    --return '2.0.0-dev v2.0dev-285-g101f36a sew-devel-2_0';
    RETURN QUERY SELECT '2.0.0-dev'::varchar AS version,'v2.0dev'::varchar
AS tag,
                        '285'::varchar AS build, 'g101f36a'::varchar AS
hash,
                        'sew-devel-2_0'::varchar AS branch;
END;
$BODY$
  LANGUAGE plpgsql IMMUTABLE
  COST 100;

You can run either with "SELECT * FROM pgr_version()"

psql -U postgres -d doc -c "SELECT * FROM public.pgr_version()"
  version | tag | build | hash | branch
-----------+---------+-------+----------+---------------
2.0.0-dev | v2.0dev | 285 | g101f36a | sew-devel-2_0
(1 row)

Or just "SELECT pgr_version()"

psql -U postgres -d doc -c "SELECT public.pgr_version()"
                  pgr_version
------------------------------------------------
(2.0.0-dev,v2.0dev,285,g101f36a,sew-devel-2_0)
(1 row)

I think this should satisfy everyone. No? :wink:

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

11

On 29/05/13 06:20, Daniel Kastl wrote:

Looks great as long as it returns all the information required for debugging pg route that can not be got from elsewhere. It returns information about which version of the pgr code has been used, but does it include the version information for the dependency of libraries used to build pgr?

For example if I use select postgis_version

I get 2.0 USE_GEOS=1 USE_PROJU=1 USE_STATS=1

postgis_full_version

POSTGIS="2.0.0 r9605" GEOS="3.3.8-CAPI-1.7.82 PROJ="Rel.4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, release 2012/10/08" LIBJSON="UNKNOWN" RASTER

With this information I would known everything required to build the right version of postgis, does'nt pgr include some support from some 3rd party libraries?

I am just thinking about the next time, a bug report is raised!

Dave.
*//* <https://www.google.co.uk/search?client=ubuntu&hs=k3u&channel=cs&biw=1325&bih=870&q=libraries&spell=1&sa=X&ei=-5GlUeK1GOmX0QWK94DwBw&ved=0CCwQvwUoAA&gt;

On Wed, May 29, 2013 at 1:17 PM, Daniel Kastl <daniel@georepublic.de <mailto:daniel@georepublic.de>> wrote:

    On Wed, May 29, 2013 at 12:53 PM, Stephen Woodbridge
    <woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

        On 5/28/2013 11:40 PM, Daniel Kastl wrote:

            On Wed, May 29, 2013 at 12:18 PM, Stephen Woodbridge
            <woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>
            <mailto:woodbri@swoodbridge.com
            <mailto:woodbri@swoodbridge.com>>> wrote:

                On 5/28/2013 10:14 PM, Daniel Kastl wrote:

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

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

                I'm fine with have to two functions.

                pgr_full_version() - this would be the full string
            with everything
                pgr_version() - this should match version of
            extension like:
                                       2.0.0-dev in
            pgrouting--2.0.0-dev.sql

                The full version string is what we want for bug reporting.
                The version is what you might want to use in an
            application to
                construct if clauses based on features available in
            this or that
                version of the software.

            What about

            pgr_version() -> should match version of extension
            pgr_version("full") -> full string with everything (could
            be also "debug")

            I know this is not really important discussion, but we did
            so well in
            decreasing the number of functions and then we're having
            multiple ones
            for just getting the version information :wink:
            Also I had to add two pages to the function reference somehow.

            I still like the idea to return a record, because someone
            could pick
            what is important if used for an application, like:

            SELECT * FROM pgr_version();

            version | tag | build | hash | branch
            ----------+---------+-------+----------+---------------
            2.0.0-dev | v2.0dev | 271 | g6eeef9b | sew-devel-2_0

            So one could get the version with SELECT version FROM
            pgr_version() in
            case they really use it for some application for example;

        This would require defining a new TYPE, I suppose I we could
        return text then you could use array_to_string() to concat
        them with hyphens.

        I don't like the idea of passing arguments to get different
        strings, because I have not seen it on any other apps.

    Me neither. I would prefer to query for attributes as well.

        I would just have leave it as two functions and put them both
        on one doc page. Or if you want it parsed return a text
        array. I'm happy to make the changes that is trivial.

    Do you really need to define new types to return a table?

    I just did it like this in another function variant:
    https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_network_check.sql

    I didn't have to create a type for that.

I tried this and it works pretty well:

CREATE OR REPLACE FUNCTION public.pgr_version()
  RETURNS TABLE(
"version" varchar,
tag varchar,
build varchar,
hash varchar,
branch varchar
) AS
$BODY$
DECLARE

BEGIN
    --return '2.0.0-dev v2.0dev-285-g101f36a sew-devel-2_0';
    RETURN QUERY SELECT '2.0.0-dev'::varchar AS version,'v2.0dev'::varchar AS tag,
      '285'::varchar AS build, 'g101f36a'::varchar AS hash,
      'sew-devel-2_0'::varchar AS branch;
END;
$BODY$
  LANGUAGE plpgsql IMMUTABLE
  COST 100;

You can run either with "SELECT * FROM pgr_version()"

psql -U postgres -d doc -c "SELECT * FROM public.pgr_version()"
  version | tag | build | hash | branch
-----------+---------+-------+----------+---------------
2.0.0-dev | v2.0dev | 285 | g101f36a | sew-devel-2_0
(1 row)

Or just "SELECT pgr_version()"

psql -U postgres -d doc -c "SELECT public.pgr_version()"
                  pgr_version
------------------------------------------------
(2.0.0-dev,v2.0dev,285,g101f36a,sew-devel-2_0)
(1 row)

I think this should satisfy everyone. No? :wink:

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

12

On Wed, May 29, 2013 at 2:33 PM, Dave Potts <dave.potts@pinan.co.uk> wrote:

On 29/05/13 06:20, Daniel Kastl wrote:

Looks great as long as it returns all the information required for
debugging pg route that can not be got from elsewhere. It returns
information about which version of the pgr code has been used, but does it
include the version information for the dependency of libraries used to
build pgr?

For example if I use select postgis_version

I get 2.0 USE_GEOS=1 USE_PROJU=1 USE_STATS=1

postgis_full_version

POSTGIS="2.0.0 r9605" GEOS="3.3.8-CAPI-1.7.82 PROJ="Rel.4.8.0, 6 March
2012" GDAL="GDAL 1.9.2, release 2012/10/08" LIBJSON="UNKNOWN" RASTER

Hi Dave,

With CMAKE we know about the versions of PostgreSQL, CGAL, Boost for
example.
I don't think we need to include PostgreSQL and PostGIS version as you can
just query for it with the PostgreSQL and PostGIS functions.
Except we think it's important to know with which version it was compiled.
For example someone might just copy old pgRouting accidentally with a
database dump and functions might have conflicts with PostGIS for example.
But PostGIS doesn't do this either, right?

Indeed we could think about to add the version of Boost and CGAL. There are
no other dependencies at the moment.
I changed the function to return a table, so it's quite easy to add a cgal
and boost column actually.

@Steve
To answer my own question:

How do you manage to get the updated VERSION file to be part of the last
commit?
I added the pre-commit file as you said, but every time I commit, the
VERSION file changes and is marked as modified. And on the Github
repository I'm theoretically always one commit hash behind.

With "git commit -a" staged files that have been modified and deleted get
included.
I usually didn't use "-a", so need to be more careful now when doing a
commit :wink:

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

13

On 5/29/2013 1:51 AM, Daniel Kastl wrote:

On Wed, May 29, 2013 at 2:33 PM, Dave Potts <dave.potts@pinan.co.uk
<mailto:dave.potts@pinan.co.uk>> wrote:

    On 29/05/13 06:20, Daniel Kastl wrote:

    Looks great as long as it returns all the information required for
    debugging pg route that can not be got from elsewhere. It returns
    information about which version of the pgr code has been used, but
    does it include the version information for the dependency of
    libraries used to build pgr?

    For example if I use select postgis_version

    I get 2.0 USE_GEOS=1 USE_PROJU=1 USE_STATS=1

    postgis_full_version

    POSTGIS="2.0.0 r9605" GEOS="3.3.8-CAPI-1.7.82 PROJ="Rel.4.8.0, 6
    March 2012" GDAL="GDAL 1.9.2, release 2012/10/08" LIBJSON="UNKNOWN"
    RASTER

Hi Dave,

With CMAKE we know about the versions of PostgreSQL, CGAL, Boost for
example.
I don't think we need to include PostgreSQL and PostGIS version as you
can just query for it with the PostgreSQL and PostGIS functions.
Except we think it's important to know with which version it was
compiled. For example someone might just copy old pgRouting accidentally
with a database dump and functions might have conflicts with PostGIS for
example. But PostGIS doesn't do this either, right?

Indeed we could think about to add the version of Boost and CGAL. There
are no other dependencies at the moment.
I changed the function to return a table, so it's quite easy to add a
cgal and boost column actually.

Dave we are trying to move away from optional builds. So ultimately there will be not options and you will just build it. There have been issues with various Boost versions and compiling, but I have resolved most (all?) of these issues and once you compile we have not had any runtime issues able specific boost versions that I am aware of. CGAL will hopefully go away in the future but even if it doesn't, it is very stable and we have never had a version specific bug related to that.

So why does PostGIS do this? They work very closely with the development of GEOS, GDAL, and PROJ and in fact so closely that certain features in postgis are dependent on very recent versions of these libraries. It is essential that this information is report with a bug because often the same developers that are wrapping the functions into postgis are also developing the underlying library code also.

I'm not opposed to adding CGAL and Boost versions but I'm not sure of the value. @Daniel, I'm fine with adding these if you want.

  @Steve
To answer my own question:

    How do you manage to get the updated VERSION file to be part of the
    last commit?
    I added the pre-commit file as you said, but every time I commit,
    the VERSION file changes and is marked as modified. And on the
    Github repository I'm theoretically always one commit hash behind.

With "git commit -a" staged files that have been modified and deleted
get included.
I usually didn't use "-a", so need to be more careful now when doing a
commit :wink:

Yes, but if you have added files use "git status" first to see what files might be new that need to be added.

-Steve

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

14

Hi Dave,

With CMAKE we know about the versions of PostgreSQL, CGAL, Boost for
example.
I don't think we need to include PostgreSQL and PostGIS version as you
can just query for it with the PostgreSQL and PostGIS functions.
Except we think it's important to know with which version it was
compiled. For example someone might just copy old pgRouting accidentally
with a database dump and functions might have conflicts with PostGIS for
example. But PostGIS doesn't do this either, right?

Indeed we could think about to add the version of Boost and CGAL. There
are no other dependencies at the moment.
I changed the function to return a table, so it's quite easy to add a
cgal and boost column actually.

Dave we are trying to move away from optional builds. So ultimately there
will be not options and you will just build it. There have been issues with
various Boost versions and compiling, but I have resolved most (all?) of
these issues and once you compile we have not had any runtime issues able
specific boost versions that I am aware of. CGAL will hopefully go away in
the future but even if it doesn't, it is very stable and we have never had
a version specific bug related to that.

So why does PostGIS do this? They work very closely with the development
of GEOS, GDAL, and PROJ and in fact so closely that certain features in
postgis are dependent on very recent versions of these libraries. It is
essential that this information is report with a bug because often the same
developers that are wrapping the functions into postgis are also developing
the underlying library code also.

I'm not opposed to adding CGAL and Boost versions but I'm not sure of the
value. @Daniel, I'm fine with adding these if you want.

I already added Boost, but I didn't add CGAL.
Boost was possible after finding the right hints in the CMake source file.
For CGAL I couldn't find variables for version information, so I just leave
it away. If someone wants to invest time in this, then please go ahead.
Otherwise I agree with Steve that CGAL is a) stable, b) optional and c)
hopefully not needed anymore some time in the future.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de