<div dir="ltr">Hi Regina,<div><br></div><div>Our plan was to follow this schema:</div><div><a href="https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Guidelines-and-Standards#git-branching-model">https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Guidelines-and-Standards#git-branching-model</a><br></div><div>... maybe with some simplifaction.</div><div><br></div><div>Git repositorites sometimes get a bit "messy" with too many branches, if merged branches are not deleted afterwards.</div><div>But in general relevant branches should be only:</div><div><ul><li>master (=latest release version)</li><li>develop (=about the same as "trunk" in SVN)</li></ul><div>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.</div></div><div><br></div><div>Daniel</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 12:27 PM, Paragon Corporation <span dir="ltr"><<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> Maybe you can explain the versioning that postgis uses and what events you<br>
use to change version numbers.<br>
<br>
> For us, develop is always the NEXT major in development release branch and<br>
develop_X_X_X is a minor development bugfix release branch. And master is<br>
the current stable tagged release.<br>
<br>
> I'm not opposed to changing this to make it easier for others to work with<br>
us. This is just what I thought other projects were doing and seemed to be a<br>
logical and simple to follow process.<br>
<br>
> Input is always welcome.<br>
<br>
</span>PostGIS is still on svn for core -- though we have a github mirror which<br>
more or less follows our svn pattern<br>
<br>
For us the trunk (marked svn-trunk and the default branch) is our<br>
development branch -- so that would be what will become 2.2.0 and has<br>
version 2.2.0dev to reflect its still in development<br>
<br>
For each stable branch we have a branch -- 2.0 (which is version 2.0.7dev),<br>
2.1 (which is versioned 2.1.6dev<br>
<br>
Then for releases we have tags - 2.0.6, 2.1.5, etc.<br>
<br>
<br>
When we start a new minor (has new functions and can be upgraded with an<br>
in-place upgrade) - which happens as soon as we release the last minor, we<br>
tag our current master (trunk), then create a new stable branch, and then<br>
bump the master to new version.<br>
<br>
So for example when we released 2.0.0<br>
<br>
We created a tag of current master (svn-trunk) as 2.0.0, created a new<br>
branch (2.0) from master (this was tagged as 2.0.1SVN (legacy reasons new<br>
convention is to add dev at end) ), and then changed master to 2.1.0dev<br>
<br>
This happened again when we went from 2.0 to 2.1 (as you can see in our<br>
branches and tags here -- <a href="https://github.com/postgis/postgis" target="_blank">https://github.com/postgis/postgis</a> ) so our<br>
svn-trunk became 2.2.0dev<br>
<br>
<br>
So in a nutshell, we never have two branches (or tags) that have the same<br>
version number.  By version number, I'm talking about when you install<br>
PostGIS / pgRouting<br>
<br>
With<br>
<br>
CREATE EXTENSION postgis;<br>
CREATE EXTENSION pgrouting;<br>
<br>
What you see when you run:<br>
SELECT postgis_full_version();<br>
SELECT * FROM pgr_version();<br>
<br>
As well as what you see for version when you run<br>
<br>
SELECT name, default_version,installed_version<br>
FROM pg_available_extensions<br>
WHERE name IN('postgis', 'pgrouting');<br>
<span class=""><br>
<br>
Thanks,<br>
Regina<br>
<br>
<br>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
</span><a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66,99,171)" target="_blank">daniel.kastl@georepublic.de</a><br>Web: <a href="http://georepublic.info" style="color:rgb(66,99,171)" target="_blank">http://georepublic.info</a></span><div><br></div><div><br></div><div><br></div></div></div>
</div>