emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Simon Thum <simon.thum@gmx.de>
To: Bastien <bzg@altern.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: [DEV] New git workflow
Date: Tue, 20 Mar 2012 23:35:43 +0100	[thread overview]
Message-ID: <4F69063F.40600@gmx.de> (raw)
In-Reply-To: <87mx7cf613.fsf@altern.org>

Hi all,

as discussion started anyway, I'd like to mention that I see some 
problem with maint, that is, it only ever pertains to the latest 
release. It's hard to hotfix and release old versions in the proposed model.

Moreover, maint is bound quite tightly to master. maint seems like a 
somewhat safer master to me - I fail to see a big difference between 
them. One may want to count that as a bonus; I don't. Part of the reason 
is that sometimes releases have commits that simply don't belong into 
master, like specific version increments.

Many projects use the IMO more sane model of release branches (or 
maintenance branches, if you prefer) for major releases. Minor ones are 
tagged on those branches, and back-porting critical fixes is much 
cleaner: Fixes and development go to master, fixes which should be 
back-ported are cherry-picked onto the release branches. When desired, a 
new release is tagged. Releases only come from release branches, of course.

If you like to see an example, the X server uses such a model:


I guess a decision should mostly be based on how significant the use 
case "back-port fix" is to org-mode. The "safer master" role of maint 
could of course be retained in a stable branch which points to something 
like master@{1 month ago}.



On 03/20/2012 01:51 AM, Bastien wrote:
> 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!

  parent reply	other threads:[~2012-03-20 21:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-20  0:51 [DEV] New git workflow Bastien
2012-03-20  7:03 ` Achim Gratz
2012-03-20  7:24   ` Achim Gratz
2012-03-20 10:40   ` Bastien
2012-03-20 19:20     ` Achim Gratz
2012-03-21  0:02       ` Bastien
2012-03-21  0:23         ` Bastien
2012-03-20 10:47   ` Bastien
2012-03-20 22:35 ` Simon Thum [this message]
2012-03-20 22:27   ` Achim Gratz
2012-03-21  8:46     ` Simon Thum
2012-03-21  9:01       ` Achim Gratz
2012-03-21 22:38         ` Simon Thum
2012-03-24 11:05   ` Daniel Dehennin
2012-03-24 20:08     ` Simon Thum
2012-03-24 19:29       ` Nick Dokos
2012-04-01  9:26         ` Simon Thum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F69063F.40600@gmx.de \
    --to=simon.thum@gmx.de \
    --cc=bzg@altern.org \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).