From: Bastien <firstname.lastname@example.org> To: Achim Gratz <Stromeko@nexgo.de> Cc: email@example.com Subject: Re: [DEV] New git workflow Date: Tue, 20 Mar 2012 11:40:40 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <87fwd3ycsu.fsf@Rainer.invalid> (Achim Gratz's message of "Tue, 20 Mar 2012 08:03:13 +0100") Hi Achim, Achim Gratz <Stromeko@nexgo.de> writes: > Bastien <email@example.com> 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. Agreed. What I want on top of this is a to have a branch where *every* commit corresponds to a single release. >> - 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. There is one important deviation: so far we could commit changes to maint and _not_ make a release. From now on, every commit to maint should correspond to a release. > 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. No. All hotfix branches should merge into master regularily. When hotfix contains enough fixes for a bugfix release, then we merge it to maint, and process with release. My main goal is this: have a branch with one commit = one release. >> 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. Yes. -- Bastien
next prev parent reply other threads:[~2012-03-20 10:39 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-20 0:51 Bastien 2012-03-20 7:03 ` Achim Gratz 2012-03-20 7:24 ` Achim Gratz 2012-03-20 10:40 ` Bastien [this message] 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 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --cc=Stromeko@nexgo.de \ --firstname.lastname@example.org \ --subject='Re: [DEV] New git workflow' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).