First issue, one does not simply just start using a develop branch. CI only triggers off the 'main' branch, which is master by default. If we move to the way you propose, then we need to file a ticket with INFRA I believe. That can be done, but its not like we just start doing it one day.
The current method is, when we cut a release- we make a new branch of that release. Master is treated like dev. If you want the latest stable, you would check out branch-0.13.0 . This is the way most major projects (citing Spark, Flink, Zeppelin), including Mahout up to version 0.10.x worked. To your point, there being a lack of a recent stable- that's fair, but partly that's because no one created branches with the release for 0.10.? - 0.12.2. For all intents and purposes, we are (now once again) following what you propose, the only difference is we are treating master as dev, and "branch-0.13.0" as master (e.g. last stable). Larger features go on their own branch until they are ready to merge- e.g. ATM there is just one feature branch CUDA. That was the big take away from this discussion last time- there needed to be feature branches, as opposed to everyone running around either working off WIP PRs or half baked merges, etc. To that end- "website" was a feature branch, and iirc there has been one other feature branch that has merged in the last couple of months but I forget what it was at the moment. Trevor Grant Data Scientist https://github.com/rawkintrevo http://stackexchange.com/users/3002022/rawkintrevo http://trevorgrant.org *"Fortunate is he, who is able to know the causes of things." -Virgil* On Mon, Jun 19, 2017 at 8:02 PM, Pat Ferrel <p...@occamsmachete.com> wrote: > Perhaps there is a misunderstanding about where a release comes > from—master. So any release tools we have should work fine. It’s just that > until you are ready to pull the trigger, development is in develop or more > strictly a “getting a release ready” branch called a release branch. This > sounds like a lot of branches but in practice it’s trivial to merge and > purge. Everything stays clean and rapid fire last minute fixes are isolated > to the release branch before going into master. > > The original reason I brought this up is that our Git tools now allow > committers to delete old cruft laden branches that are created and > ephemeral with this method. > > > On Jun 19, 2017, at 5:52 PM, Pat Ferrel <p...@occamsmachete.com> wrote: > > I just heard we are not using git flow (the process not the tool), we are > checking unclean (untested in any significant way) changes to master? What > is the develop branch used for? > > The master is unstable most all the time with the old method, in fact > there is *no stable bundle of source ever* without git flow. With git flow > you can peel off a bug fix and merge with master and users can pull it > expecting that everything else is stable and like the last build. This has > bit me with Mahout in the past as I’m sure it has for everyone. This > doesn’t fix that but it does limit the pain to committers. > > If we aren’t going to use it, fine but let’s not agree to it then do > something else. If it’s a matter of timing ok, I understood from Andrew’s > mail below there was no timing issue but I expect there will be Jenkins or > Travis issues to iron out. > > For reference: http://nvie.com/posts/a-successful-git-branching-model/ < > http://nvie.com/posts/a-successful-git-branching-model/> I have never > heard of someone who has tried it that didn’t like it but it takes a leap > of faith unless you have git in your bones. > > > On Apr 22, 2017, at 10:42 AM, Andrew Musselman <andrew.mussel...@gmail.com> > wrote: > > Okay develop it is; I'll cut a develop branch from master right now. > > As we go, if people forget and push to master, we can merge those changes > into develop. > > In addition, I'm making a 'website' branch for all work on the new version > of the site. > > On Sat, Apr 22, 2017 at 10:36 AM, Pat Ferrel <p...@occamsmachete.com> > wrote: > > > There are tools to implement git-flow that I haven’t used and may have > > some standardization built in but I think “develop” is typical and safe. > > > > > > On Apr 22, 2017, at 10:33 AM, Andrew Musselman < > andrew.mussel...@gmail.com> > > wrote: > > > > Cool, I'll make a new dev branch now. > > > > Dev, develop, any preference? > > > > On Sat, Apr 22, 2017 at 10:30 AM, Pat Ferrel <p...@occamsmachete.com> > > wrote: > > > >> It hasn't been often but I’ve been bit by it and had to ask users of a > >> dependent project to checkout a specific commit, nasty. > >> > >> The main affect would be to automation efforts that are currently wip. > >> > >> On Apr 22, 2017, at 10:25 AM, Andrew Musselman < > > andrew.mussel...@gmail.com> > >> wrote: > >> > >> I've worked in shops where that was the standard flow, in hg or git, and > > it > >> worked great. I'm in favor of it especially as we add contributors and > > make > >> it easier for people to submit new work. > >> > >> Have we had that many times when master got messed up? I don't recall > > more > >> than a few, but in any case the master/dev branch approach is solid. > >> > >> On Sat, Apr 22, 2017 at 10:06 AM, Pat Ferrel <p...@occamsmachete.com> > >> wrote: > >> > >>> I’ve been introduced to what is now being called git-flow, which at > it’s > >>> simplest is just a branching strategy with several key benefits. The > > most > >>> important part of it is that the master branch is rock solid all the > > time > >>> because we use the “develop” branch for integrating Jiras, PRs, > > features, > >>> etc. Any “rock solid” bit can be cherry-picked and put into master or > >>> hot-fixes that fix a release but still require a source build. > >>> > >>> Key features of git-flow: > >>> The master becomes stable and can be relied on to be stable. It is > >>> generally equal to the last release with only stable or required > >> exceptions. > >>> Develop is where all the integration and potentially risky work > happens. > >>> It is where most PRs are targeted. > >>> A release causes develop to be merged with master and so it maintains > > the > >>> stability of master. > >>> > >>> The benefits of git-flow are more numerous but also seem scary because > >> the > >>> explanation can be complex. I’ve switched all my projects and Apache > >>> PredictionIO is where I was introduced to this, and it is actually > quite > >>> easy to manage and collaborate with this model. We just need to take > the > >>> plunge by creating a persistent branch in the Apache git repo called > >>> “develop”. From then on all commits will go to “develop” and all PRs > >> should > >>> be created against it. Just after a release is a good time for this. > >>> > >>> https://datasift.github.io/gitflow/IntroducingGitFlow.html < > >>> https://datasift.github.io/gitflow/IntroducingGitFlow.html> > >>> > >>> What say you all? > >> > >> > > > > > > >
