[pgrouting-dev] Repository cleanup (branches)

[Stephen Woodbridge]

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_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.

-Steve