[pgrouting-dev] Repository cleanup (branches)

[Stephen Woodbridge]

On 5/3/2013 9:46 PM, Daniel Kastl wrote:
>
>
>
> On Sat, May 4, 2013 at 4:14 AM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
>     On 5/3/2013 2:45 PM, Daniel Kastl wrote:
>
>         Over the time several branches were created in the pgRouting
>         repository.
>         Some were for Google Summer of Code or development of new
>         algorithms,
>         others for packaging and some for working on the new 2.0 release.
>
>         As Steve has completed a lot of tasks for a new release, I think
>         it's
>         time to do some repository cleanup: mainly get rid of useless
>         branches
>         and give them proper names.
>
>         I have created a list of the current branches and added comments
>         (2nd
>         sheet):
>         https://docs.google.com/a/__georepublic.de/spreadsheet/__ccc?key=0AiIg1pkkh___MRdGQzOEhyaXlndkN3eHdGNkpyQ0pM__ZFE#gid=4
>         <https://docs.google.com/a/georepublic.de/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE#gid=4>
>
>         By deleting the Debian packaging related branches, nothing gets
>         lost. It
>         was an attempt to automate packaging, but this might be done better.
>
>         The most important change would be to introduce a "pgr-1.x" and a
>         "pgr-2.x" branch, which should be "safe" to use. Releases
>         (alpha, beta,
>         RC, stable) would be tagged within these branches.
>         The "master" branch then would contain the current state of
>         development.
>
>         To achieve this, I would propose to:
>
>           1. Branch "master" as "pgr-1.x"
>           2. Merge "sew-devel-2_0" branch into "master"
>           3. Then branch "master" as "pgr-2.x"
>
>         Does this make sense?
>
>
>     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.
>
>     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
>
>     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:
>
>                                +--pgr-1.08-o   +--pgr-1.09-o
>                 +- pgr-1.x----/---------------/--__---->
>     master----/---(merge sew-devl-2_0)---\---------->(__pgr-3.0-dev)------>
>
>     +--pgr-2.0-beta1-o-pgr-2.0-__beta2-o
>
>     etc. the 'o' is were we cut a release.
>
>     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.
>
>     So I think we are saying the same thing.
>
>
>
> Hi Steve,
>
> I thought once more about it and what a new pgRouting user might expect,
> who wants to compile pgRouting.
> 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:
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Following this branching model has the advantage, that many developers
> should be familiar with it and that it should be "good enough". ;-)
>
> 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.
> So I would say, that as a user you expect that "master" isn't a (broken)
> development branch ;-)
>
> As the article mentions, there may be three types of branches:
>
>   *
>   * Feature branches
>   * Release branches
>   * Hotfix branches
>
> 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>.
> I think all these branches can be temporary, but there might be reasons
> to keep them, ie.:
>
>   * They haven't been merged yet (ie. darp branches)
>   * Google Summer of Code branches to document a students work (ie.
>     those starting with gsoc-)
>   * They have been merged to the current version, but some people might
>     want to make the changes also available for elder releases (ie. trsp)
>
> 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.
> Since we might still support 1.x for some time though I would create an
> extra branch for this.
>
> I have modified the Spreadsheet accordingly.
> Do you think this is better?

Daniel,

I'm happy following the model on the link you referenced.
We should ask we can save a pdf ot that page in github and reference it 
in out development standards.

-Steve