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
