[Kdenlive-devel] Git workflow
jb at kdenlive.org
Thu Nov 3 15:36:44 UTC 2011
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:
> We could adopt it completely and have something like this:
> - master: always stable, only gets bug fixes and production-ready
> - 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
> - 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.
More information about the Kdenlive