emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] [DEV] New git workflow


From: Bastien
Subject: [O] [DEV] New git workflow
Date: Tue, 20 Mar 2012 01:51:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Hi all,

our current git workflow is pretty well summarised by Achim -- we have
two main branches, master and maint, and we (try to) follow these rules:

   If it's a bugfix for something broken in a release version, commit to
   maint and merge maint back into master.

   If implementing a new feature or fixing something not yet released,
   commit to master.

On top of that, some local development happens in dedicated branches.

The role of master is clear: it contains latest mature developments,
which are either (1) bugfixes merged from maint, (2) features merged
from dedicated branches or (3) features developed in master directly.

The role of maint is less clear: it is both a "hotfix" branch and a
release branch for bugfix releases.  The reason for this branch was
first that we need to keep a production-like version of Org in sync 
with Emacs.  

The main problem I see With this workflow is that releases are made
from two different branches: bugfix releases are made from maint and
major releases are made from master.  This doesn't look right to me.

So I suggest to use three branches with these rules:

- master: the main persistent branch.  This is were regular development
  goes.  This branch is merged back to the maint branch when we release
  a new major version.  No release happens directly from this branch.

- maint: the "production" persistent branch.  This branch is dedicated
  to the release process: when hot fixes are hot enough, we merge the
  hotfix branch to the maint branch and release a bugfix release.  When
  the master branch (where hot fixes are also merged to) is mature and
  well tested, we merge master into maint and release a major version.

- hotfix-7.XX.XX: the transient branch for hotfixes.  Severe bugs are
  fixed there first, then merged back to maint when this makes sense.
  The branch is created when we need it and deleted when we don't need
  it anymore.

This workflow looks clearer to me.  Here are the advantages I see:

1) *all releases happen on the same branch* (the maint branch): it is
   easier to keep this branch in sync with Emacs and we can also add
   git hooks to automate the release process.

2) the master branch *is* the development branch: yes, pretty unusual.
   At least as unusual as not having two mailing lists, one for users
   and one for devs.  But I want to stick to what makes this list a
   great place: regular users are invited to live on the bleeding edge
   and to contribute patches on the "development" branch, the one they
   will clone first.

So, what's next?

I will merge 7.8.06 into Emacs.

Nothing should be committed to maint anymore before the next release.

Important bug fixes for 7.8.06 all go to a new branch hotfix-7.8.06.

Usual development goes to master, from where we regularily merge the
hotfix branch.

We'll get rid of the hotfix branch when releasing 7.8.07 or 7.9.

...

Finally, two positive things from the mess I put and went through: 
I learned more about git, and I experienced once again how patient
and helpful people can be on this list.  Thanks to all again!

-- 
 Bastien



reply via email to

[Prev in Thread] Current Thread [Next in Thread]