In addition to numerous other problems- its not 'just that simple' Git has to be setup and replumbed to close PRs based on merge to develop, as well as making that the default for new PRs.
IIRC we tried doing this last year- it was a mess, we went back. We're not doing _that_ much work on master to necessitate it, its a lot of work to change over, it does increase the learning curve to coming on board with the project. Spark, Flink, Zeppelin, other TLPs- use master for the so called- "develop" branch and latest release branch as stable. I am in favor of this method. You use develop branch/stable master for projects when you are trying to push new features out daily. We have been trying to solve the "stuck on scala-2.10" riddle since last release. IIRC, the issue was around the scopt being somehow stuck to pulling in scala-2.10. I don't think we've added a serious feature since then. All current users for prod-deployments should be buildling from mahout-0.13 branch anyway, and then applying their own tricks to get the build to work for scala-2.11 (e.g. delete the drivers or build with maven). my .02 On Fri, Mar 2, 2018 at 2:32 PM, Pat Ferrel <pat.fer...@gmail.com> wrote: > Trevor said -1 to git flow. > > I agree this is a good example of one nice feature. Master is always > pristine. > > > From: Andrew Palumbo <ap....@outlook.com> <ap....@outlook.com> > Reply: dev@mahout.apache.org <dev@mahout.apache.org> < > dev@mahout.apache.org> > Date: March 2, 2018 at 12:30:09 PM > To: dev@mahout.apache.org <dev@mahout.apache.org> <dev@mahout.apache.org> > Subject: Re: Spark 2.x/scala 2.11.x release > > Pat - Not sure if you thought I meant -1 or you're saying -1 to `git-flow`. > I'm +1 on it, and this is a perfect time to make the transition, since we > don't have a `develop` branch, now we can revert `master` to its state at > the 0.13.0 release, create a `develop` at the same time, branched from the > `mahout-0.13.0` tag, cherrypick commits that we want from post - > `mahout-0.13.0` and keep the rest of the work, currently on `master` e.g.: > all of the work that Trevor did on the multi-artifact release on a feature > branch, which we can hopefully release soon as 0.13.2. > > > So I'm essentially suggesting that we take this as an opportunity to move > to this `git-flow` style of managing our repo. > > > > > ________________________________ > From: Pat Ferrel <p...@occamsmachete.com> > Sent: Friday, March 2, 2018 3:00:15 PM > To: Trevor Grant; dev@mahout.apache.org > Subject: Re: Spark 2.x/scala 2.11.x release > > -1 on git flow? > > What are your reasons? I use it in 3-4 project, one of which is Apache PIO. > I’d think this would be a good example of why it’s nice. right now our > master is screwed up, with git flow it would still have 0.13.0, which is > what we are talking about releasing with minor mods. > > > From: Trevor Grant <trevor.d.gr...@gmail.com> <trevor.d.gr...@gmail.com> > Reply: dev@mahout.apache.org <dev@mahout.apache.org> < > dev@mahout.apache.org> > > Date: March 2, 2018 at 11:36:52 AM > To: Mahout Dev List <dev@mahout.apache.org> <dev@mahout.apache.org> > Subject: Re: Spark 2.x/scala 2.11.x release > > I'm +1 for a working scala-2.11, spark-2.x build. > > I'm -1 for previously stated reasons on git-flow. > > tg > > > On Fri, Mar 2, 2018 at 1:24 PM, Andrew Palumbo <ap....@outlook.com> wrote: > > > > > Sounds Good. I'll put out a proposal for the release, and we can go Over > > it and vote if we want to on releasing or on the scope. I'm +1 on it. > > > > > > Broad strokes of what I'm thinking: > > > > > > - Checkout a new branch "features/multi-artifact-build-22xx" from master > > @ the `mahout-0.13.0` release tag. > > > > > > - Revert master back to release tag. > > > > > > - Checkout a new `develop` branch from master @the `mahout-0.13.0` > release > > tag. > > > > > > - Cherrypick any commits that we'd like to release (E.g.: SparseSpeedup) > > onto `develop` (along with a PR ad a ticket). > > > > > > - Merge `develop` to `master`, run through Smoke tests, tag master @ > > `mahout-0.13.1`(automatically), and release. > > > > > > This will also get us to more of a git-flow workflow, as we've discussed > > moving towards. > > > > > > Thoughts @all? > > > > > > --andy > > > > > > > > > > > > > > ________________________________ > > From: Pat Ferrel <pat.fer...@gmail.com> > > Sent: Wednesday, February 28, 2018 2:53:58 PM > > To: Andrew Palumbo; dev@mahout.apache.org > > Subject: Re: Spark 2.x/scala 2.11.x release > > > > big +1 > > > > If you are planning to branch off the 0.13.0 tag let me know, I have a > > speedup that is in my scala 2.11 fork of 0.13.0 that needs to be released > > > > > > From: Andrew Palumbo <ap....@outlook.com><mailto:ap....@outlook.com> > > Reply: dev@mahout.apache.org<mailto:dev@mahout.apache.org> < > > dev@mahout.apache.org><mailto:dev@mahout.apache.org> > > Date: February 28, 2018 at 11:16:12 AM > > To: dev@mahout.apache.org<mailto:dev@mahout.apache.org> < > > dev@mahout.apache.org><mailto:dev@mahout.apache.org> > > Subject: Spark 2.x/scala 2.11.x release > > > > After some offline discussion regarding people's needs for Spark and 2.x > > and Scala 2.11.x, I am wondering If we should just consider a release for > > 2.x and 2.11.x as the default. We could release from the current master, > or > > branch back off of the 0.13.0 tag, and release that with the upgraded > > defaults, and branch our current multi-artifact build off as a feature. > Any > > thoughts on this? > > > > > > --andy > > >
