[pgrouting-dev] Version numbering suggestion

Stephen Woodbridge woodbri at swoodbridge.com
Fri Dec 26 07:57:52 PST 2014 

On 12/26/2014 1:18 AM, Paragon Corporation wrote:
> Sounds good to me.  Only question I have is
> By release -- do you mean like a stable branch (so bug-fixes can be
> committed to it) or that it is the last one you released and no further
> changes can be made to it.

In git, a tag and a branch are virtually the same thing. They both mark 
a point in the change history of the software. A "release" is an 
administrative event. In theory once you make a release it can not be 
changed and we create a tag representing that point in history.

At anytime, we can make a branch from a tag or another branch which will 
instantiate copy of the source tree at the reference from which you 
created the branch.

1) make a release 2.0.0 and
2) tag it as v2.0.0 and
3) create a branch develop_2_0_1 (from the tag v2.0.0) for a potential 
bug fix release and
4) create a branch develop (from the tag v2.0.0) for the next feature 
release

at the time of the release all these are identical. select pgr_version();

develop branch reports:

pgrouting-2.0.0-78-gabde224 develop

where the version is "pgrouting-2.0.0" plus 78 commits ahead of that 
with the git index of "gabde224" in the "develop" branch.

"master" and "develop-2_0_1" branch reports:

pgrouting-2.0.0-0-gd6ed2cb master

where the version is "pgrouting-2.0.0" and 0 commits ahead of that with 
the git index of "gd6ed2cb" in the "master" branch

The oddity of reporting "develop-2_0_1" branch as master is only because 
the branch tag only gets updated after we make a change to the branch. 
and there have been no changes committed to the "develop-2_0_1" branch yet.

So we have a very specific versioning scheme, and I have a commit hook 
that makes sure things stay updated.

We could change this and immediately bump the version number on the 
branch which avoid the confusion when the branch is created, but it 
creates the same confusion later because pgrouting-2.0.1 really that or 
some prerelease develop leading up to the the release. This is only 
clear if you look at the full version.

Our currently tagging scheme actually allows use to checkout exactly the 
source that is referenced in the full version info for example to check 
a bug against that source. If someone reports an issue against a version 
we can immediately determine to a high degree of specificity where if 
came from.

-Steve

CREATE OR REPLACE FUNCTION pgr_version()
RETURNS TABLE(
         "version" varchar,
         tag varchar,
         build varchar,
         hash varchar,
         branch varchar,
         boost varchar
     ) AS
$BODY$
/*
.. function:: pgr_version()

    Author: Stephen Woodbridge <woodbri at imaptools.com>

    Returns the version of pgrouting,Git build,Git hash, Git branch and 
boost
*/

DECLARE

BEGIN
     RETURN QUERY SELECT '${PGROUTING_VERSION_STRING}'::varchar AS version,
                         '${PGROUTING_GIT_TAG}'::varchar AS tag,
                         '${PGROUTING_GIT_BUILD}'::varchar AS build,
                         '${PGROUTING_GIT_HASH}'::varchar AS hash,
                         '${PGROUTING_GIT_BRANCH}'::varchar AS branch,
 
'${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION}'::varchar 
AS boost;
END;
$BODY$
LANGUAGE plpgsql IMMUTABLE;

> I think having a branch of the latest stable is important, particularly
> if someone runs into a bug and doesn't want to go to the development
> branch that may add more functions.
> Aside from that.  My main suggestion is the develop version and released
> version should not have the same version number since this just causes
> confusion for people.
> Thanks,
> Regina
>
> ------------------------------------------------------------------------
> *From:* pgrouting-dev-bounces at lists.osgeo.org
> [mailto:pgrouting-dev-bounces at lists.osgeo.org] *On Behalf Of *Daniel Kastl
> *Sent:* Thursday, December 25, 2014 11:19 PM
> *To:* pgRouting developers mailing list
> *Subject:* Re: [pgrouting-dev] Version numbering suggestion
>
> Hi Regina,
>
> Our plan was to follow this schema:
> https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Guidelines-and-Standards#git-branching-model
> ... maybe with some simplifaction.
>
> Git repositorites sometimes get a bit "messy" with too many branches, if
> merged branches are not deleted afterwards.
> But in general relevant branches should be only:
>
>   * master (=latest release version)
>   * develop (=about the same as "trunk" in SVN)
>
> Other branches may be there for convenience, to try out new things, or
> some other reason. But they are not important for the standard user.
>
> Daniel
>
>
>
> On Fri, Dec 26, 2014 at 12:27 PM, Paragon Corporation <lr at pcorp.us
> <mailto:lr at pcorp.us>> wrote:
>
>
>
>     >Maybe you can explain the versioning that postgis uses and what
>     events you
>     use to change version numbers.
>
>     > For us, develop is alwaysthe NEXT major in development release branch and
>     develop_X_X_X is a minor development bugfix release branch. And
>     master is
>     the current stable tagged release.
>
>     > I'm not opposed to changing this to make it easier forothers to work with
>     us. This is just what I thought other projects were doing and seemed
>     to be a
>     logical and simple to follow process.
>
>     >Input is always welcome.
>
>     PostGIS is still on svn for core -- though we have a github mirror which
>     more or less follows our svn pattern
>
>     For us the trunk (marked svn-trunk and the default branch) is our
>     development branch -- so that would be what will become 2.2.0 and has
>     version 2.2.0dev to reflect its still in development
>
>     For each stable branch we have a branch -- 2.0 (which is version
>     2.0.7dev),
>     2.1 (which is versioned 2.1.6dev
>
>     Then for releases we have tags - 2.0.6, 2.1.5, etc.
>
>
>     When we start a new minor (has new functions and can be upgraded with an
>     in-place upgrade) - which happens as soon as we release the last
>     minor, we
>     tag our current master (trunk), then create a new stable branch, and
>     then
>     bump the master to new version.
>
>     So for example when we released 2.0.0
>
>     We created a tag of current master (svn-trunk) as 2.0.0, created a new
>     branch (2.0) from master (this was tagged as 2.0.1SVN (legacy
>     reasons new
>     convention is to add dev at end) ), and then changed master to 2.1.0dev
>
>     This happened again when we went from 2.0 to 2.1 (as you can see in our
>     branches and tags here -- https://github.com/postgis/postgis ) so our
>     svn-trunk became 2.2.0dev
>
>
>     So in a nutshell, we never have two branches (or tags) that have the
>     same
>     version number.  By version number, I'm talking about when you install
>     PostGIS / pgRouting
>
>     With
>
>     CREATE EXTENSION postgis;
>     CREATE EXTENSION pgrouting;
>
>     What you see when you run:
>     SELECT postgis_full_version();
>     SELECT * FROM pgr_version();
>
>     As well as what you see for version when you run
>
>     SELECT name, default_version,installed_version
>     FROM pg_available_extensions
>     WHERE name IN('postgis', 'pgrouting');
>
>
>     Thanks,
>     Regina
>
>
>     _______________________________________________
>     pgrouting-dev mailing list
>     pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.info
>
>
>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>

More information about the pgrouting-dev mailing list