On Thu, Jan 23, 2014 at 2:41 PM, Andrea Bollini <a.boll...@cineca.it> wrote: > According to this workflow it looks better manage bugs as PR against 4.x > than as PR against the master. In this way if we miss to merge something to > the master we can do it later also in one go for multiple patches/bug fixes.
We currently do the opposite - as soon as we decide a minor release is coming out, we scour master for bugfixes and backport them. The two approaches are really interchangable and equally difficult, so as long as we stick to either one of them, we should be fine. > The opposite direction is not so easy as it requires cherry pick and is > "untracked" by git, so we need to assure by ourself that we don't miss bug > fix. I'm not sure what you mean by untracked by git. Do you mean regular merges of the release branch to the master branch after each fix is commited to the release branch? You're right in that this is not possible to do in the other direction because on master, there are non-bugfix changes intermingled with bugfixes. But a merge is something you have to do from the command line (i.e. GitHub doesn't make it easier; well, unless you want to fire additional PRs for the same thing, which we recently agreed is not a good thing because it fragments the discussion to many places), just like cherry-pick. What advantages do you see to a merge as opposed to a cherry-pick? Or did you mean something else? > Also the famous GitFlow branching model > http://nvie.com/posts/a-successful-git-branching-model/ > suggest to work on the maintenance branch and after merge that in the > develop branch (in our case the master). Like I said above, the important thing is to standardize on one way. This happens to describe the other way that the one we use, but I really see no advantages to it. Oh, and I forgot to mention one advantage to our current model I see. It assures that if we forget to port the bugfix, it will be in all subsequent releases, it will only miss from an old release. In the reverse scenario, if we forget, it's fixed in the old version and not in the future versions. I admit this doesn't happen to us very often, but it's possible. The second important advantage is in case of conflict (i.e. for complex fixes that touch code with unrelated changes between the two branches). If we fix on master and have a problem with conflicts that are hard to resolve, we can just decide to give up on the fix for old release. If we start from the old one, we *have to* push through to fix the the newer branch. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
