[pgrouting-dev] Version numbering suggestion

[Paragon Corporation]

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.
 
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-S
tandards#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> wrote:




> Maybe you can explain the versioning that postgis uses and what events you
use to change version numbers.

> For us, develop is always the 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 for others 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
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev





-- 

Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.info 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20141226/387b211e/attachment-0001.html>