kristw commented on issue #6131: [SIP-12] Proposal for Branch Management and Release Process URL: https://github.com/apache/incubator-superset/issues/6131#issuecomment-475739936 but if the fix is applied on `support/1.2.x` branch according to this diagram, the fix will never be merged back to master. https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches How could we apply the same fix for both `master` and `support/1.2.x` without cherry-pick? *Support Branches* > Support branches are not really covered in GitFlow, but are essential if > you need to maintain multiple major versions at the same time. You could > use support branches for supporting minor releases as well. If you are just > supporting the majors, then name your branch support/<major>.x (i.e > support/1.x), to support minors use support/<major>.<minor>.x or > support/<major>.<minor>.0. (i.e support/1.3.x or support/1.3.0) On Fri, Mar 22, 2019 at 11:35 AM Dave Smith <[email protected]> wrote: > Thanks for reply @kristw <https://github.com/kristw> ... I understood > that SIP-12 was largely about release schedule etc, etc., and I think we > agree that it is largely separable from the implementation in terms of > branch mechanics (ie not specified and needn't be by something like > gitflow, which just provides the abstractions for implementing it). > > To respond to one point you raised: patching previous releases is very > doable in Git Flow. For example, see here: > https://stackoverflow.com/a/33052352/3407502 That is what I intended to > address in "Daily Development, Item 2" of my comment. Applying the fix on > the earliest supported release and merging forward through subsequent > supported releases has the additional benefit of completely avoiding > cherry-picks and throwing away the history. > > Avoiding cherry picks is, IMO, the biggest benefit of switching to > GitFlow. Otherwise, much of the react process is transferable... > cherry-picking seems like an implementation detail in their model, and it > looks like it causes them a lot of trouble, see here > <https://github.com/react-native-community/discussions-and-proposals/issues/53> > for example. I'm actually surprised to see react uses cherry picks so > heavily, as it throws away history and context and is prone to producing > bugs as you lose track of which branches have changes, where they > originated, where subsequent edits were made etc, and with a little bit of > rigor they are *almost completely avoidable*. > > A little discipline around release management (ie directing bug PRs > towards the correct fix branch) would allow such patches to be smoothly and > unidirectionally merged, with history, in a much less risky, chaotic way, > to all of the branches, IMO. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/apache/incubator-superset/issues/6131#issuecomment-475733651>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABlTe1RBSPBaVrfj6iaXrUKQpedgiAEEks5vZSJegaJpZM4Xkuj3> > . > -- *Krist Wongsuphasawat, PhD* http://kristw.yellowpigz.com
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
