search

almende / vis

⚠️ This project is not maintained anymore! Please go to https://github.com/visjs
7.85k stars 1.48k forks source link

switch to develop as the default branch #4198

Closed DanielRuf closed 5 years ago

DanielRuf commented 5 years ago

Every contributor who forks this repo gets master as default so we have to recreate our PRs.

Please change the default branch in the project settings to develop.

mojoaxel commented 5 years ago

@DanielRuf Thanks for your idea to improve this project. The decision to use a separate development branch and a stable master branch is in vis from its beginning. It was a decision by the almende-core team.

I'm also not a big fan of that but It makes sense for big projects to keep the public version as bug-free as possible. This of course only works if bug-fixes are merged and released in a timely manner. This is no longer the case!!

So I'm with that we should not have a seperate develop branch, but I think the better way would be to get rid of developcompletely and use only master in the future.

I'm not willing to do this at the moment. I have no Idea what will break.. Let's get rid of develop during the split of modules (#2405).

DanielRuf commented 5 years ago

I think you misunderstood my point. We have to switch to develop in the repo settings as default instead of master. Both branches will still exist.

DanielRuf commented 5 years ago

Because If you create a PR, the template says develop should be used otherwise the PR is closed. Changing branches then produces issues.

mojoaxel commented 5 years ago

The problem is, that the default branch in github also defines the default sources view and the default branch if cloned (as far as I know). I'm not willing to make this decision.

DanielRuf commented 5 years ago

Well, why not? As stated in my issue, new contributors will create branches from the wrong branch (master).

mojoaxel commented 5 years ago

Well, why not?

  1. This project is based on the Gitflow-Workflow. Not everybody may like this (including me) but this is just how the creators of this project (many years ago) decided it for good reasons!
  2. Because the develop branch is untested and quite unstable at the moment.
  3. Because the develop branch has no dist folder. This folder is very much needed for the examples, the web-page and users that just want to use vis.
  4. The package release process is based on master. No if this would work out-of the box with develop.

As stated in my issue, new contributors will create branches from the wrong branch (master).

That contributors should use the develop branch is not intuitive but well documented.

@DanielRuf Maybe you want to take your time to read up on all the existing issues discussing this topic and many more concerning the release process.

To make one thing clear: It's not my project, but I have write access and I'm willing to execute community decisions. But only if a minority of the community stands behind a decision and not one person.

What do others think?

mojoaxel commented 5 years ago

@DanielRuf You are really(!) very welcome to help with this project. I'm more than willing to simplify things but you have to acknowledge that this project is not a simple library but a real big monster with a long history and a muddled source base. If we can make sure nothing breaks I'm the first person to get rid of the develop branch and make a release after every pull-request!

DanielRuf commented 5 years ago

develop branch is untested and quite unstable at the moment

master too in general

make a release after every pull-request!

Never saw this, not a great idea imho.

This folder is very much needed for the examples, the web-page and users that just want to use vis

Dist files should not be tracked. And there is gh-pages as npm project and often used in CI. npm can store other files than in the GitHub repo.

techtonik commented 5 years ago

Looking at the front page I thought that the project died year ago.

image

Keeping active development in master will prevent such confusion.

DanielRuf commented 5 years ago

Or by just switching the default branch to the develop branch in the GitHub repo settings.

techtonik commented 5 years ago

@DanielRuf so why you would need master then?

https://www.endoflineblog.com/gitflow-considered-harmful#the-master-develop-split-is-redundant

DanielRuf commented 5 years ago

In general master is for merging develop into it when creating a release (what we do in many big repos). It is not redundant.

DanielRuf commented 5 years ago

Not sure who writes this blog but not every commit is tagged. I think the person never used GitFlow in bigger projects where you have things like dev and release branches.

DanielRuf commented 5 years ago

You can also ignore merge commits in the history or filter them out + there is --ff and --no-ff.

And we have protected branches in many cases.

Let's not discuss about the pros and cons of the GitFlow model but make decisions here. The easiest is to change the default branch in the repo settings.

DanielRuf commented 5 years ago

https://github.com/almende/vis/issues/4198#issuecomment-441274898

Release process and how zsers can use vis would be untouched by the change as you can use only in Travis CI and others to specify the build tasks based on the branch name.

techtonik commented 5 years ago

In general master is for merging develop into it when creating a release (what we do in many big repos). It is not redundant.

https://yourlogicalfallacyis.com/bandwagon

Jumping on that train, some popular repos from Python ecosystem abandoned that practice. Popular != big.

Not sure who writes this blog but not every commit is tagged.

https://yourlogicalfallacyis.com/strawman

Common, it is not that hard to understand what does he mean - take a look at current master. Eight last comments are tagged, and the rest do not affect the source code. https://github.com/almende/vis/commits/5563fc616885578ad51b2dfa6ccf70ccebf06126 There is no reason to isolate those untagged commits into separate branch. If you find one - link it here and we can continue.

Let's not discuss about the pros and cons of the GitFlow model but make decisions here. The easiest is to change the default branch in the repo settings.

https://www.youtube.com/watch?v=-1CE4P8qqPE :D Sorry, couldn't resist.

techtonik commented 5 years ago

Every contributor who forks this repo gets master as default so we have to recreate our PRs.

I agree with the problem, and your problem statement is awesome and I'd +1 that, but I don't like the solution that still requires too much git kung fu.

DanielRuf commented 5 years ago

Jumping on that train, some popular repos from Python ecosystem abandoned that practice. Popular != big

Sorry but I'm also active contributor at such big projects.

too much git kung fu

Not sure what you mean. A simple rebase is often sufficient. Or recloning the repo.

As it is not planned to change the default branch, let's close this discussion.

techtonik commented 5 years ago

I opened a separate ticket to discuss OneFlow.