[pgrouting-dev] Version numbering suggestion

[Daniel Kastl]

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> 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/ff4df7bd/attachment.html>