[dev] Git branch naming

[Michael M Slusarz]

Once again, I may be in the minority with this, but the recent run-up  
to releases has indicated several shortcomings when it comes to our  
current git organization.  I may be beating a dead horse with some of  
these concerns, and I know some have looked at other solutions (e.g.  
git-subtree), but these are my observations:

1. WE NEED TO GET RID OF THE develop BRANCH

As I have mentioned before, the develop branch does not make much  
sense.  People seem to point to this article like it is the bible when  
it comes to the master/develop situation (and I believe this article  
was used when we first made this distinction):

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

Unfortunately, it doesn't really match the way that **WE** develop  
and, IMHO, is not useful for our purposes.

Instead of explaining why I think our old setup is bogus, I will  
instead describe what I think we should be using instead:

   + The release of Horde 5.0 should be immediately branched into HORDE_5.
   + 'master' again becomes the HEAD branch.
     - For now, 'master' should be thought of as what will eventually  
become Horde 5.1
     - *ALL* developers should be using 'master' going forward
   + Bugs discovered on master need to be backported (i.e.  
cherry-picked) into the HORDE_5 branch.
     - We should *NEVER* be merging (i.e. 'git merge') to/from  
branches for release versions.

What does this setup give us?

   + Proper browsing of the current code state
     - Someone who goes to git.horde.org (or github) immediately sees  
our most up-to-date code.
     - This is consistent with other projects (browsing source code  
always goes to the most up-to-date code).
   + Enforces our release rules
     - This setup makes it much easier to ensure that minor releases  
(i.e. 5.0.x) are ONLY bug fixes or small features that are  
easily/cleanly backported
     - Since each individual commit it required to be back-ported, it  
reduces the tendency to allow feature creep in maintenance releases  
(I'll admit, I am one of the worst when it comes to this distinction.  
Reorganizing the development tree in this matter eliminates the  
incentive to do this).
   + It prevents merge issues.
     - Merging a large group of commits can be very confusing.
     - Merging large commit groups may require someone to fix  
conflicts who did not modify the original code.
     - By cherry picking, instead of merging, it requires the person  
to immediately resolve issues after they have just finished working  
with the code, so it is more likely any merge resolutions will be more  
accurate.

We could keep a develop branch for code that will go into Horde 6.  At  
some point in the future, we would know when we are going to work for  
a new major branch and at that moment, we merge develop into master  
and do away with develop.  develop should NOT be tracked for  
bug/enhancement changes.

2. Framework libraries need to go into their own repositories

I believe we have already agreed that this is needed, and was  
something we are going to look at after Horde 5 is released.  Recent  
work on Horde_Imap_Client reiterates how important this is (since, at  
this point, it is extremely difficult to keep "development" branches  
of framework libraries).  Not sure if git subtree can help us here or  
not.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]