Repository navigation
[FEATURE REQUEST] Changing develop branch to become the repo's default branch. #967
Description
Problem
I think our current system of merging PRs to develop then making a release to master has some flaws to it.
- In order to use Linked Issues when merging PRs, the PRs have to be merged to the default branch aka
master. By merging them intodevelopfirst, Linked Issues aren't triggered and issues aren't closed when merged. - Our repo relies on some Actions that need to be merged into
masterfor it to work (workflow_runfor example). By limiting PRs intomasteronly during releases, testing the action becomes difficult because we can only test it during the next release.
Suggested feature
I think we should change our develop branch to become the default branch. This would solve the above 2 problems. The current master branch can then be changed to something like a stable-release branch or something similar.
Essentially:
- Rename
mastertostable-release - Rename
developtomaster - Change GitHub setting to point to
developas the default branch.
Why should we have this feature?
We won't have to manually close Issues anymore. Changes that we want people to see right away when they visit the repo (README.md, CONTRIBUTING.md, GitHub Actions) would also be present after we merge.
Additional information
No response
Reacted by David
Activity
Panquesito7 commentedon Dec 14, 2021
Good idea 👍 actually, we can keep the
masterbranch as-is (with that name), and just change the default one todevelop, and keep the GitHub Pages branch tomaster, which is the stable version. What do you think? 🙂Thomas-Boi commentedon Dec 15, 2021
That works too. I think as long as people understands which branch to work off on, it'll work well. The reason why I suggest the name change is because contributors sometimes open PRs into
masterand notdevelopamacado commentedon Dec 15, 2021
When we would follow 1 and 2 there would be no
developbranch for step 3 (since it's renamed). This confused me while reading it the first time. I suggest:mastertostable(to not get confused by the new naming strategy of github regardingmainbranch)developas the default branchstableAn issue could be that some people refer to the
masterbranch when importing/including this project. Altough this can be considered as bad practice, it's out in the field and this would introduce a breaking change. We also need to check where themasterbranch is "hard coded" in any actions/links. I'm not sure if GitHub auto-redirects a renamed branch (like they to with repository names).I can understand what you mean, but on the other hand you can see it like: "The issue isn't closed yet, because it's not yet released. It's in
developstage". In my opinion this is fine, let me give you an example:I'm looking trought devicon.dev and missing an icon "my-supercool-icon", I search for an issue (to see if it has already been created) and see it's in
mergedstate. So I'm wondering: Why It's not on the website (and I can't use it)? I would have to deep dive into the repository structure to see it's indevelopmentstage and not been released yet.According to this example I think it's not to bad to have no auto-close feature on the
developbranch. This problem might be solved with some auto-labeling feature which applies a "currently indevelopbranch" or "released in vX.X.X" label to an issue.Thomas-Boi commentedon Dec 15, 2021
That's a fair point. I didn't think about it like that. I'll look around and see if there's Action that we can use to do this. I think we discussed this a long time ago since I'm having deja vu.
Thomas-Boi commentedon Dec 22, 2021
I'll go with making a script that labels issues as being in
develop