[Kdenlive-devel] Git workflow
avilla at freebsd.org
Thu Nov 3 07:49:22 UTC 2011
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.
Of course we can strip off the integration branch, but that would mean
either keeping features from being tested until they're very stable
(unlikely to happen if there's no test) or making master unstable, risking
to delay releases because of non-ready features (as it's already
happened). I think that feature branches can really help to improve
Kdenlive stability, that's why I wouldn't exclude them. About release
branches, I'm not sure: does my idea sound sane?
A note to translators: if I understood correctly, you will not work onto
Kdenlive Git repository, but will have a dedicated repository
So, please, comment!
Alberto Villa, FreeBSD committer <avilla at FreeBSD.org>
Please, won't somebody tell me what diddie-wa-diddie means?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 314 bytes
Desc: This is a digitally signed message part.
More information about the Kdenlive