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@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@lists.osgeo.org
[mailto:pgrouting-dev-bounces@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@pcorp.us
<mailto:lr@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@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.info
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
