github git-flow workflow model

[enuggetry]

Not a feature of 1.12.4 but rather a suggestion of how we might manage github projects moving forward.

A suggestion was given my @keiranmraine to deploy a git-flow workflow model. Here, master would always be the last release and development starts in a dev branch.

I'll put it in a 1.12.4 milestone. move it if necessary.

[rbuels]

Are a lot of people running off of master now?

[rbuels]

@nathandunn @cmdcolin do you guys want to do this? We would just need to coordinate a bit to make sure we are using the right branch.

If there are a lot of people that are downloading and using master directly, we should probably do this.

[rbuels]

Actually why don't we just have a stable branch that is just updated to the latest release every time we release. Then everybody doesn't have to update their working copies.

[nathandunn]

@rbuels I feel like the new "best-practice" is to have "master" as stable and "development" as development with releases into master as you suggested. I think that is what folks would expect anyway, so it might be better to follow the convention.

[rbuels]

There isn't one "best practice" about this. There's the classic heavy git-flow which is development/master/feature branches/etc from 2010, http://nvie.com/posts/a-successful-git-branching-model/, which is basically what you guys are describing, then there's the lighter github flow, which is what we're basically doing right now: https://guides.github.com/introduction/flow/. Atlassian more or less calls this the "feature branch workflow" in their workflow-comparison guide.

I've used git-flow before, I never found that it offered much that the github-flow/feature-branch flow didn't.

What's the problem that you guys are trying to solve here? That master is often broken? That people want to be able to get the latest release by pulling from master? That JBrowse doesn't release enough for the releases to have up to date features?

If we get back on a good release cadence, the releases will become useful again, and if we get good testing in Travis, the master branch will not have as many bugs.

So what are we trying to accomplish?

[rbuels]

And most of the github-based tools (like travis) have default support for the github-flow model, which reduces our maintenance burden a bit. They support heavy git-flow too, with some configuration, of course.

At the end of the day, it's whatever makes you guys happier.

[rbuels]

@cmdcolin could you weigh in here

[nathandunn]

I think the problem that we've run into is actually (let's see if I'm right) is that a lot of the tooling expects master to be the latest release, for example when you using npm / npmjs and calling github directly. Anyway, would be good to get @keiranmraine 's input as he initially suggested it (as well as @cmdcolin 's ) as well, as my memory is a bit foggy.

I think the proper way to think about it, is as what happens when JBrowse is just another npm dependency, or plugins are being installed via npm, etc. etc. Maybe its all moot so long as you are providing regular releases.

[cmdcolin]

I personally like github flow also (e.g. the lightweight just merge feature branches to master) but I could probably work around pretty much any branching model. Having less obstacles in the way of getting features and bugfixes out is great though :) The caveat I guess with the NPM install is that installing jbrowse via NPM straight from github is a little weird because I think that would install from master by default. Most times with NPM install if you had a package on npm.org you'd have the latest stable version that was released to npm though

[nathandunn]

I agree. I started to read this https://stackoverflow.com/questions/14858075/set-the-develop-branch-as-the-default-for-a-pull-request but it was even less helpful.

The key, like Colin said is just releasing regularly on npmjs.. after that I think it’s whatever is easiest.

Nathan

On Feb 6, 2018, at 4:06 PM, Colin Diesh notifications@github.com wrote:

I personally like github flow also (e.g. the lightweight just merge feature branches to master) but I could probably work around pretty much any branching model. Having less obstacles in the way of getting features and bugfixes out is great and anticipate new normal releases.

The caveat I guess with the NPM install is that installing jbrowse via NPM straight from github is a little weird because I think that would install from master by default. Most times with NPM install if you had a package on npm.org you'd have the latest stable version that was released to npm though

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[keiranmraine]

You called? It's completely a question of the skill level of people working on the project. You certainly can't expect contributors outside the core team to necessarily adhere to the process.

The advantage of the more heavy workflow is that you never encounter the problem of a hotfix occurring after a feature has been merged into master prior to a release. BUT, it's also (counter intuitively) easier for someone with a lower level of git foo to work with as they never have to worry about branching from tags or commits just simply git hf hotfix start 1.1.X

Hotfixes always branch from master (and auto merge back when finished). Features branch from develop. Test each feature in isolation, when ready to start release process merge all to dev (resolve conflicts) and then start a release branch. At this point all hotfixes have also been consolidated. The release branch theoretically only lives as long as it takes to confirm all tests and acceptance and very minor fixes.

Anyway that's my 2 pence/cents

[nathandunn]

I like the concept of hot fixes (and have used them), but I never end up seeing them work well in practice with this type of group (distributed with few main developers).

However, if it has worked well for your group, I’m always happy to give anything a shot.

On Feb 7, 2018, at 12:50 AM, Keiran Raine notifications@github.com wrote:

You called? It's completely a question of the skill level of people working on the project. You certainly can't expect contributors outside the core team to necessarily adhere to the process.

The advantage of the more heavy workflow is that you never encounter the problem of a hotfix occurring after a feature has been merged into master prior to a release. BUT, it's also (counter intuitively) easier for someone with a lower level of git foo to work with as they never have to worry about branching from tags or commits just simply git hf hotfix start 1.1.X

Hotfixes always branch from master (and auto merge back when finished). Features branch from develop. Test each feature in isolation, when ready to start release process merge all to dev (resolve conflicts) and then start a release branch. At this point all hotfixes have also been consolidated. The release branch theoretically only lives as long as it takes to confirm all tests and acceptance and very minor fixes.

Anyway that's my 2 pence/cents

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GMOD/jbrowse/issues/975#issuecomment-363699026, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt2qqPFfut91hgH2PKV8pz0o01Jnd77ks5tSWPwgaJpZM4R6YcB.

[nathandunn]

We decided to go with a default "dev" branch and master is now a stable release branch. I updated the PR's to reflect that.

[nathandunn]

I'm sure we'll continue to evolve this process as time goes on.