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

Tue May 28 06:00:45 PDT 2013

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>> 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 at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>