Which translates into exactly what you suggest if we are maintaining release branches.
On Jun 22, 2017, at 10:45 AM, Pat Ferrel <p...@occamsmachete.com> wrote: Actually I think git flow would merge it into master and tag it with an annotated tag like “0.13.0.jira-123” to reference the bug fix or some other naming scheme. Since the bug is “important” it is treated like what the blog post calls a “hotfix” so the head of master is still stable with hotfixes applied even if the merge does not warrant a binary release. The master branch hygiene is maintained by checking WIP into develop or a feature branch, hotfixes and releases go into master. There is also a mechanism to maintain release branches if the project warrants, which may be true of Mahout. On Jun 21, 2017, at 3:25 PM, Trevor Grant <trevor.d.gr...@gmail.com> wrote: So right now, if there was a bug in 0.13.0 that needed an important patch- why not just merge it into master and git branch "branch-0.13.0" On Wed, Jun 21, 2017 at 4:26 PM, Dmitriy Lyubimov <dlie...@gmail.com> wrote: > PS. but i see the rational. to have stable fixes to get into release. > perhaps named release branches is still a way to go if one cuts them early > enough. > > On Wed, Jun 21, 2017 at 2:25 PM, Dmitriy Lyubimov <dlie...@gmail.com> > wrote: > >> >> >> On Wed, Jun 21, 2017 at 2:17 PM, Pat Ferrel <p...@occamsmachete.com> > wrote: >> >> Since merges are done by committers, it’s easy to retarget a > contributor’s >>> PRs but committers would PR against develop, >> >> IMO it is anything but easy to resolve conflicts, let alone somebody >> else's. Spark just asks me to resolve them myself. But if you don't have >> proper target, you can't ask the contributor. >> >> and some projects like PredictionIO make develop the default branch on >>> github so it's the one contributors get by default. >>> >> That would fix it but i am not sure if we have access to HEAD on github >> mirror. Might involve INFRA to do it And in that case it would amount >> little more but renaming. It would seem it is much easier to create a >> branch, "stable master" or something, and consider master to be ongoing > PR >> base. >> >> -1 on former, -0 on the latter. Judging from the point of both > contributor >> and committer (of which I am both).it will not make my life easy on > either >> end. >> >> >
