<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 10.00.9200.17183"></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial>Sounds good to me.  Only question I have is 
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=633281506-26122014><FONT color=#0000ff 
size=2 face=Arial>Regina</FONT></SPAN></DIV><BR>
<DIV lang=en-us class=OutlookMessageHeader dir=ltr align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> pgrouting-dev-bounces@lists.osgeo.org 
[mailto:pgrouting-dev-bounces@lists.osgeo.org] <B>On Behalf Of </B>Daniel 
Kastl<BR><B>Sent:</B> Thursday, December 25, 2014 11:19 PM<BR><B>To:</B> 
pgRouting developers mailing list<BR><B>Subject:</B> Re: [pgrouting-dev] Version 
numbering suggestion<BR></FONT><BR></DIV>
<DIV></DIV>
<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>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="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><SPAN><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><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-SIZE: 13px; FONT-FAMILY: arial,sans-serif; BORDER-COLLAPSE: collapse">Georepublic 
UG & Georepublic Japan<BR>eMail: <A style="COLOR: rgb(66,99,171)" 
href="mailto:daniel.kastl@georepublic.de" 
target=_blank>daniel.kastl@georepublic.de</A><BR>Web: <A 
style="COLOR: rgb(66,99,171)" href="http://georepublic.info" 
target=_blank>http://georepublic.info</A></SPAN>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV><BR></DIV></DIV></DIV></DIV></BODY></HTML>