Prepare a Git Branching Model.

[cvvergara]

Difficulty level: Unknown
Urgency: Before coding starts.
preconditions: After several ISSUES being marked as feature request .
How its going to be implemented: Based on how this tagging scheme works, we can decide how to handle the branching model:

• can be based on issues preconditions/postconditions?,
• based on difficulty?,
• a combination?
• Branches with meaningful names.

http://nvie.com/posts/a-successful-git-branching-model/

[sarthak0415]

made a branch named gsoc-develop.

[cvvergara]

gsoc-develop in @sarthak-0415 's fork.
and now we have a gsoc-develop in the main repository.
Its a good moment to experiment on how to handle the branching model.

So, lets experiment the follwing:
@sarthak-0415 works on his fork, and when the code gets to a stable state (like no errors when compiling) we do:
update the content from sarthak-0415/osm2pgrouting with pgRouting/osm2pgrouting.
Updating can be easily done with 2 mouse clicks:
1st: Create a Pull request in Sarthak's branch
2nd: Merge the Pull request in the main repo.

[dkastl]

I think we should work towards v3.0.0, so we can tag issues with this version.
Later each commit will show up in the release notes, so doing this nicely will make a nice release note.

[cvvergara]

On 1:01:00 they use the diagram of the git branching model.
https://www.youtube.com/watch?v=rqKGX2LJOmU

[cvvergara]

This was used for the GSOC2015. So I am closing.