New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

github git-flow workflow model #975

Closed
enuggetry opened this Issue Feb 6, 2018 · 14 comments

Comments

Projects
None yet
5 participants
@enuggetry
Contributor

enuggetry commented Feb 6, 2018

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.

@enuggetry enuggetry added this to the 1.12.4 milestone Feb 6, 2018

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 6, 2018

Are a lot of people running off of master now?

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 6, 2018

@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

This comment has been minimized.

Collaborator

rbuels commented Feb 6, 2018

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

This comment has been minimized.

Contributor

nathandunn commented Feb 6, 2018

@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

This comment has been minimized.

Collaborator

rbuels commented Feb 6, 2018

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

This comment has been minimized.

Collaborator

rbuels commented Feb 6, 2018

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

This comment has been minimized.

Collaborator

rbuels commented Feb 6, 2018

@cmdcolin could you weigh in here

@nathandunn

This comment has been minimized.

Contributor

nathandunn commented Feb 7, 2018

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

This comment has been minimized.

Contributor

cmdcolin commented Feb 7, 2018

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

This comment has been minimized.

Contributor

nathandunn commented Feb 7, 2018

@keiranmraine

This comment has been minimized.

Contributor

keiranmraine commented Feb 7, 2018

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

This comment has been minimized.

Contributor

nathandunn commented Feb 7, 2018

@nathandunn

This comment has been minimized.

Contributor

nathandunn commented Feb 7, 2018

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 nathandunn closed this Feb 7, 2018

@nathandunn

This comment has been minimized.

Contributor

nathandunn commented Feb 7, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment