[Kdenlive-devel] Git workflow

[jb]

On Thursday 03 November 2011 08:49:22 Alberto Villa wrote:
> Hi all!
> 
> To complete svn2git rules I need your opinion on what will be our
> preferred workflow in Git.
> 
> First thing first, have a look here:
> http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
> 
> We could adopt it completely and have something like this:
> - master: always stable, only gets bug fixes and production-ready
> features;
> - next (or whatever name you like): integration branch to test new
> features during development, gets bug fixes (merged from master) and
> features when there is something to test (i.e., no "breaking everything"
> commits, but "add experimental support for X to Y" commits, merged
> from feature branches), and it's the branch we and our bleeding edge
> users will run;
> - release branches: one for minor release (0.7, 0.8...), get merge commits
> from master when ready to release - I'm afraid we need those to address
> urgent bug fixes (see 0.7.7.1), otherwise tagging master would be just
> easier;
> - feature branches: local or remote, it's where "breaking everything"
> commits go, be it features or complex bug fixes.

I have no experience with git, so I am not the best person to comment. However 
it seems a good idea to have "master" that would always be in a "releasable" 
state (when translations are ready), and "next" that would be more like our 
current svn trunk.

I am not sure about the "release" branches. We don't really have the energy to 
maintain several "stable" branches, so my idea would be that when we make a 
new Kdenlive release (from the "master" branch), we wait like 2 weeks before 
merging changes from the "next" branch. That way, if some serious issue 
appears in these 2 weeks after a release, we can easily make a new minor 
release fixing just a few bugs from the previous release.

That would avoid having too many branches around... but again, I am not used 
to git so if anyone else thinks it's easier to branch releases, I am ok.

regards
jb