From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [DEV] New git workflow Date: Tue, 20 Mar 2012 08:03:13 +0100 Message-ID: <87fwd3ycsu.fsf@Rainer.invalid> References: <87mx7cf613.fsf@altern.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:57361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9t6T-0000Tr-8L for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 03:03:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9t6Q-0002jE-UK for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 03:03:32 -0400 Received: from plane.gmane.org ([80.91.229.3]:38886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9t6Q-0002gr-Js for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 03:03:30 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S9t6M-000307-PV for emacs-orgmode@gnu.org; Tue, 20 Mar 2012 08:03:26 +0100 Received: from pd9eb3751.dip.t-dialin.net ([217.235.55.81]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 08:03:26 +0100 Received: from Stromeko by pd9eb3751.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Mar 2012 08:03:26 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Bastien writes: > 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. That ain't necessarily so. IMHO, the release always has to be done from maint (that's the whole purpose of it), preceded by a merge from master if and only if a major release is done. > 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. So far no deviation from today. > - 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. You would have to push this branch out to the public repo, otherwise the other people with access to the repo can't use it. For instance, Carsten has already committed to maint again, because he can't see your bugfix branch. All things considered, the hotfix branch and maint should almost always point to the same commit. In other words, all hotfix branches should merge into maint first and then maint back into master. The only advantage of version-specific hotfix branches I can see is if you want to be able to fix bugs in several releases seperately (e.g. 7.8.06 in Emacs 24.1, 7.x.yy in Emacs 24.2 etc.). Also, the setup would have to be slightly different in that case: branch the hotfix from the release commit and then keep adding bugfixes and merging into maint. That would require an enormous amount of coordination and discipline from all maintainers and committers, as several branches would have to keep merging into both maint and master. > This workflow looks clearer to me. I suggest you try this first in a disposable repo clone, if possible together with all other commiters to the public repo. It is a valid setup and suppports some things that you can't do very well today, but it makes things more complicated than the current workflow (which maybe need to be spelled out more explicitly). > 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. See above, that was always how it was supposed to work. > 2) the master branch *is* the development branch: yes, pretty unusual. Not really unusual, there are more examples of this. > 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. Once you've pushed it out to the repo you shouldn't delete it, even when merged back into maint. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada