[pgrouting-dev] Repository cleanup (branches)

[Daniel Kastl]

On Sat, May 4, 2013 at 4:14 AM, Stephen Woodbridge
<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




-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130504/e9b3b6ae/attachment.html>