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

[Daniel Kastl]

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

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 at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130528/c2cfda13/attachment.html>