Re: [O] [DEV] New git workflow
Hi Nick, I did not mean to imply git is not capable of working that way. It's more a question of what is accepted practice and most importantly, what fits the problem you actually have. The difference between both approaches, it seems to me, shows when there is a difference between the fix is it would have looked when done right from the first day on, and the fix as it looks when introduced later. Daggy fixes' mental image is to incrementally fix your release branches (or how you call them) each the in way it needs to be fixed. Cherry-picking usually implies (but does not mandate!) fix on master, then go back. Git's support for the other way round could be better, e.g. by introducing a DAGGY_FIX_HEAD and repo mode so you don't need to alternate cherry-pick, tag, checkout, ... To me the mental image behind is the main difference, and what is better depends on the fix and the project and what not. Just my 2c. Cheers, Simon On 03/24/2012 08:29 PM, Nick Dokos wrote: Simon Thumsimon.t...@gmx.de wrote: Hi Daniel, On 03/24/2012 12:05 PM, Daniel Dehennin wrote: Simon Thumsimon.t...@gmx.de writes: It seems that one problem with cherry-picking is the tracking of what is in which branch and from where it comes. I'm not a git neither DVCS guru, but daggyfixes[1][2][3] is saner than cherry-picking. I'm a bit biased as I mainly have git experience but to me it seems that both cherry-picking and daggy fixes have their strengths and weaknesses, and I'd rather have them both in all the VCSes but needless fights over which one is ultimately superior. Git should probably learn that thing, IMO. I'm probably missing something but what's there to learn? You check out the offending commit, make a branch off of it, commit the fix on the branch, give it a tag (so you can find it easily later on) and then merge it back anywhere you want. AFAICT, that's all there is to daggy-fixes and git is perfectly capable of doing that - no? Nick Footnotes: [1] http://mercurial.selenic.com/wiki/DaggyFixes [2] http://wiki.monotone.ca/DaggyFixes/ [3] http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
Re: [O] [DEV] New git workflow
Simon Thum simon.t...@gmx.de writes: Hi all, Hello, [...] 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. It seems that one problem with cherry-picking is the tracking of what is in which branch and from where it comes. I'm not a git neither DVCS guru, but daggyfixes[1][2][3] is saner than cherry-picking. My 2¢. Regards. Footnotes: [1] http://mercurial.selenic.com/wiki/DaggyFixes [2] http://wiki.monotone.ca/DaggyFixes/ [3] http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from -- Daniel Dehennin Récupérer ma clef GPG: gpg --keyserver pgp.mit.edu --recv-keys 0x6A2540D1 pgpTMNJvX2vJE.pgp Description: PGP signature
Re: [O] [DEV] New git workflow
Hi Daniel, On 03/24/2012 12:05 PM, Daniel Dehennin wrote: Simon Thumsimon.t...@gmx.de writes: It seems that one problem with cherry-picking is the tracking of what is in which branch and from where it comes. I'm not a git neither DVCS guru, but daggyfixes[1][2][3] is saner than cherry-picking. I'm a bit biased as I mainly have git experience but to me it seems that both cherry-picking and daggy fixes have their strengths and weaknesses, and I'd rather have them both in all the VCSes but needless fights over which one is ultimately superior. Git should probably learn that thing, IMO. Cheers, Simon My 2¢. Regards. Footnotes: [1] http://mercurial.selenic.com/wiki/DaggyFixes [2] http://wiki.monotone.ca/DaggyFixes/ [3] http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
Re: [O] [DEV] New git workflow
Simon Thum simon.t...@gmx.de wrote: Hi Daniel, On 03/24/2012 12:05 PM, Daniel Dehennin wrote: Simon Thumsimon.t...@gmx.de writes: It seems that one problem with cherry-picking is the tracking of what is in which branch and from where it comes. I'm not a git neither DVCS guru, but daggyfixes[1][2][3] is saner than cherry-picking. I'm a bit biased as I mainly have git experience but to me it seems that both cherry-picking and daggy fixes have their strengths and weaknesses, and I'd rather have them both in all the VCSes but needless fights over which one is ultimately superior. Git should probably learn that thing, IMO. I'm probably missing something but what's there to learn? You check out the offending commit, make a branch off of it, commit the fix on the branch, give it a tag (so you can find it easily later on) and then merge it back anywhere you want. AFAICT, that's all there is to daggy-fixes and git is perfectly capable of doing that - no? Nick Footnotes: [1] http://mercurial.selenic.com/wiki/DaggyFixes [2] http://wiki.monotone.ca/DaggyFixes/ [3] http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
Re: [O] [DEV] New git workflow
Hi Achim,
On 03/20/2012 11:27 PM, Achim Gratz wrote:
Sorry, but cherry-picking into multiple release branches would simply
not be a sane development model for a small project like orgmode.
I just wanted to make sure it's considered.
Whether multiple branches are involved depends mainly on what releases
one intends to maintain. The nice thing in the model is the gradual
maintenance: A really critical fix could see more backports than a nicety.
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}.
Any point in the past is no safer than today's master. The stability
that maint should provide to users is with regards to the feature set,
i.e. no gratuitous changes between releases.
Ooops, I just wanted to illustrate that stable is typically behind
master - ultimately it should be a concious decision what is stable.
I like the goal maint is set to achieve, I'm just not convinced regular
merges are a good way to ensure it - after all, merges include
everything in a branch. If there are no doubts about that on your side,
I'm fine.
Cheers,
Simon
Re: [O] [DEV] New git workflow
Simon Thum simon.t...@gmx.de writes: Whether multiple branches are involved depends mainly on what releases one intends to maintain. The nice thing in the model is the gradual maintenance: A really critical fix could see more backports than a nicety. Yes. Bastien has to make that decision since he's the one doing the maintenance. I like the goal maint is set to achieve, I'm just not convinced regular merges are a good way to ensure it - after all, merges include everything in a branch. If there are no doubts about that on your side, I'm fine. It was intended as a solution to the problem of either not getting bugfixes for the latest release or having to live on bleeding edge. It was too shortlived to judge if it had achieved that goal and how satisfied people were with it. Bastien is now trying a three-branch model since he also needs to maintain org within Emacs(*). As long as it works for him it will work for us, I'd think. (*) This should provide similar benefits to users as maint was supposed to, albeit it may not be obvious to users on how to follow that branch. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] [DEV] New git workflow
Hi Achim and Bastien, in case you fancy with the release-branch model now or in the foreseeable future, I'll probably be able to take over some of the work load in case it's a deciding factor. I've done that locally when necessary, and can claim enough git-foo. Cheers, Simon On 03/21/2012 10:01 AM, Achim Gratz wrote: Simon Thumsimon.t...@gmx.de writes: Whether multiple branches are involved depends mainly on what releases one intends to maintain. The nice thing in the model is the gradual maintenance: A really critical fix could see more backports than a nicety. Yes. Bastien has to make that decision since he's the one doing the maintenance. I like the goal maint is set to achieve, I'm just not convinced regular merges are a good way to ensure it - after all, merges include everything in a branch. If there are no doubts about that on your side, I'm fine. It was intended as a solution to the problem of either not getting bugfixes for the latest release or having to live on bleeding edge. It was too shortlived to judge if it had achieved that goal and how satisfied people were with it. Bastien is now trying a three-branch model since he also needs to maintain org within Emacs(*). As long as it works for him it will work for us, I'd think. (*) This should provide similar benefits to users as maint was supposed to, albeit it may not be obvious to users on how to follow that branch. Regards, Achim.
Re: [O] [DEV] New git workflow
Bastien b...@altern.org 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
Re: [O] [DEV] New git workflow
Achim Gratz strom...@nexgo.de writes: 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. I see you already did, had to reconfigure my refspecs for it to show up. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] [DEV] New git workflow
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien b...@altern.org 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
Re: [O] [DEV] New git workflow
Let me summarise why I propose this new workflow: 1. Users will have a way to track *only releases* from git. 2. We will be able to use git hooks in order to automate the release process on the server. 3. The workflow looks clearer to me (may be 100% subjective.) The cost of the new setup is 0: instead of committing fixes to maint, we commit them to hotfix-*. -- Bastien
Re: [O] [DEV] New git workflow
Bastien b...@gnu.org writes: Agreed. What I want on top of this is a to have a branch where *every* commit corresponds to a single release. Fair enough: a three-branch model with a release branch at the side of bugfixing and bleeding edge. 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. This is what I think is confusing: the bugfix branch (be it maint or any other) should always have the same _unless_ you want to track release specific bugfixes (which I don't think you do, but you tell me). If it changes name at every release, that just begs for a mix-up to happen when you are preparing for release and someone else tries to do one more fix. My main goal is this: have a branch with one commit = one release. Why not name it release then and keep maint for fixes? You could even install that release branch retro-actively if you want. BTW, this also means you need to prepare the release on the hotfix branch, no fier-upper on the release allowed at all (since you would need to merge that back). But as I said before, clone the repo, branch off the 7.7 release or so and re-trace the following releases via cherry-pick according to that new development model. You will quickly learn if what you have to do feels right and if you commit to that model you will have practised the moves a few times already. Another thing that I'd recommend is to not work on the public repo _at all_ and specifically never push to it, especially not automatically. The public repo should be bare (without a work tree) and any work on the server should use a clone of that repo, just like anyone else. If you prepare the releases on a fresh clone apart from the development clone, you have a stable base to work from and can nuke with no consequences if something goes wrong. Git was designed to make merges easier, but they are hard and I still botch about every tenth that I try unless they are really trivial. Once the release repo is finished, have it reviewed and then pull from it on the public repo. The reason is that it is easy to push from the wrong branch onto the wrong target, but you really have to try to do that when pulling. You can be more liberal with the normal development and bugfixing work on the development repo, but it would still be a good idea to have commits reviewed and signed off by another person before they are pulled into public. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [DEV] New git workflow
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:
http://cgit.freedesktop.org/xorg/xserver/
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}.
Cheers,
Simon
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!
Re: [O] [DEV] New git workflow
Simon Thum simon.t...@gmx.de writes:
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.
IMHO, that was never the objective.
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.
That's what it was designed to be, a way for people with (and more so
without) git access to access the latest bugfixes without the vagaries
of evolving new features.
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.
Sorry, but cherry-picking into multiple release branches would simply
not be a sane development model for a small project like orgmode.
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}.
Any point in the past is no safer than today's master. The stability
that maint should provide to users is with regards to the feature set,
i.e. no gratuitous changes between releases.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [DEV] New git workflow
Hi Achim, Achim Gratz strom...@nexgo.de writes: Fair enough: a three-branch model with a release branch at the side of bugfixing and bleeding edge. This is directly inspired from this: http://nvie.com/posts/a-successful-git-branching-model/ with some simplifications. 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. This is what I think is confusing: the bugfix branch (be it maint or any other) should always have the same _unless_ you want to track release specific bugfixes (which I don't think you do, but you tell me). I mostly want to track wrt-last-Emacs-merge specific bugs. I used the naming convention hotfix-* as suggested above because I like the idea of deleting such a branch once we don't need it anymore (i.e. once a release has been done.) Since hotfix-* role is to contain fixes for severe bugs against the last production version, their lifespan is not much (expect now, while we are testing this workflow, and while the forthcoming Emacs release puts some heat on getting as much bugfixes committed to the next 7.8.07 Org version.) If we keep a persistent maint branch, I guess we will tend to put all bugfixes there -- which I don't want. But which could make sense if those bugfixes are regularily merged back to Emacs trunk. My main goal is this: have a branch with one commit = one release. Why not name it release then and keep maint for fixes? You could even install that release branch retro-actively if you want. BTW, this also means you need to prepare the release on the hotfix branch, no fier-upper on the release allowed at all (since you would need to merge that back). Indeed. As for the names, I don't care, I just don't want to change things that are just conventions. But as I said before, clone the repo, branch off the 7.7 release or so and re-trace the following releases via cherry-pick according to that new development model. You will quickly learn if what you have to do feels right and if you commit to that model you will have practised the moves a few times already. Good idea. I will try. Another thing that I'd recommend is to not work on the public repo _at all_ and specifically never push to it, especially not automatically. The public repo should be bare (without a work tree) and any work on the server should use a clone of that repo, just like anyone else. Mhh.. something I don't get here: why should we not work on the public repo? This is the repo many people are cloning. If you prepare the releases on a fresh clone apart from the development clone, you have a stable base to work from and can nuke with no consequences if something goes wrong. (We prepare major releases on the development branch, minor ones on the hotfix-* branch.) Git was designed to make merges easier, but they are hard and I still botch about every tenth that I try unless they are really trivial. Once the release repo is finished, have it reviewed and then pull from it on the public repo. The reason is that it is easy to push from the wrong branch onto the wrong target, but you really have to try to do that when pulling. You can be more liberal with the normal development and bugfixing work on the development repo, but it would still be a good idea to have commits reviewed and signed off by another person before they are pulled into public. Okay, I now understand the problem of pushing from the wrong repo ;) Well, this is a trade-off. If developers are willing to follow these rules, okay. But I don't feel like imposing them to everyone -- especially because paying a little more attention might be enough to avoid the mess I did. Again, thanks for sharing this. Let's continue with the model I suggest and see what is better and what should be fixed. -- Bastien
Re: [O] [DEV] New git workflow
Bastien b...@altern.org writes: version, their lifespan is not much (expect now, while we are ^^ except -- Bastien
[O] [DEV] New git workflow
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
