<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 4, 2013 at 4:14 AM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 5/3/2013 2:45 PM, Daniel Kastl wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
Over the time several branches were created in the pgRouting repository.<br>
Some were for Google Summer of Code or development of new algorithms,<br>
others for packaging and some for working on the new 2.0 release.<br>
<br>
As Steve has completed a lot of tasks for a new release, I think it's<br>
time to do some repository cleanup: mainly get rid of useless branches<br>
and give them proper names.<br>
<br>
I have created a list of the current branches and added comments (2nd<br>
sheet):<br>
<a href="https://docs.google.com/a/georepublic.de/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE#gid=4" target="_blank">https://docs.google.com/a/<u></u>georepublic.de/spreadsheet/<u></u>ccc?key=0AiIg1pkkh_<u></u>MRdGQzOEhyaXlndkN3eHdGNkpyQ0pM<u></u>ZFE#gid=4</a><br>
<br>
By deleting the Debian packaging related branches, nothing gets lost. It<br>
was an attempt to automate packaging, but this might be done better.<br>
<br>
The most important change would be to introduce a "pgr-1.x" and a<br>
"pgr-2.x" branch, which should be "safe" to use. Releases (alpha, beta,<br>
RC, stable) would be tagged within these branches.<br>
The "master" branch then would contain the current state of development.<br>
<br>
To achieve this, I would propose to:<br>
<br></div>
1. Branch "master" as "pgr-1.x"<br>
2. Merge "sew-devel-2_0" branch into "master"<br>
3. Then branch "master" as "pgr-2.x"<br>
<br>
Does this make sense?<br>
</blockquote>
<br>
I can see saving the current master as pgr-1.x, this could be used to create point releases to fix bugs, or to make compatibility changes for postgres 2.x releases, etc.<br>
<br>
My plan was to at some point make my branch the new master, that can happen as soon as the current master gets save in pgr-1.x<br>
<br>
There is no need to create a pgr-2.x branch. The idea it to have the main development line in master and then to tag branches as significant points along that development. So the code stream SHOULD look like:<br>
<br>
+--pgr-1.08-o +--pgr-1.09-o<br>
+- pgr-1.x----/---------------/--<u></u>----><br>
master----/---(merge sew-devl-2_0)---\---------->(<u></u>pgr-3.0-dev)------><br>
+--pgr-2.0-beta1-o-pgr-2.0-<u></u>beta2-o<br>
<br>
etc. the 'o' is were we cut a release.<br>
<br>
So we only create a tag when we want to save the current state of things. We can create branches off the master for feature development and then they can be merged back into the master like I have done doe 2.0.<br>
<br>
So I think we are saying the same thing.<br></blockquote><div><br></div><div><br></div><div style>Hi Steve,</div><div style><br></div><div style>I thought once more about it and what a new pgRouting user might expect, who wants to compile pgRouting.</div>
<div style>Also I remembered this quite popular Git branch model, which I found not simple enough for small projects, but for some Open Source project it might be suitable:</div><div style><a href="http://nvie.com/posts/a-successful-git-branching-model/">http://nvie.com/posts/a-successful-git-branching-model/</a><br>
</div><div style><br></div><div style>Following this branching model has the advantage, that many developers should be familiar with it and that it should be "good enough". ;-)</div><div style><br></div><div style>
Well, I think in Github world the "master" branch is something 99.9 percent of all repositories have, and its's usually the branch displayed and checked out by default.</div><div style>So I would say, that as a user you expect that "master" isn't a (broken) development branch ;-)</div>
<div style><br></div><div style>As the article mentions, there may be three types of branches:</div><div style><ul style><li style></li><li>Feature branches</li><li>Release branches</li><li>Hotfix branches</li></ul></div>
<div style>I added a column to the branch list spreadsheet as this is a good classification that also fits to some of the current branches. It actually suits to all that are not marked as <drop>.</div><div style>I think all these branches can be temporary, but there might be reasons to keep them, ie.:</div>
<div style><ul style><li style>They haven't been merged yet (ie. darp branches)</li><li style>Google Summer of Code branches to document a students work (ie. those starting with gsoc-)</li><li style>They have been merged to the current version, but some people might want to make the changes also available for elder releases (ie. trsp)</li>
</ul><div style>If we follow the previously mentioned branching model, then we would create a "develop" branch (maybe from "master"?) and merge "sew-devel-2_0" into it.</div><div style>Since we might still support 1.x for some time though I would create an extra branch for this.</div>
<div style><br></div><div style>I have modified the Spreadsheet accordingly.</div><div style>Do you think this is better?</div><div style><br></div><div style>Daniel</div><div style><br></div></div><div><br></div><div><br>
</div><div><br></div></div>-- <br><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.de/" style="color:rgb(66,99,171)" target="_blank">http://georepublic.de</a></span>
</div></div>