[FEATURE REQUEST] Changing `develop` branch to become the repo's default branch.

[Thomas-Boi]

Problem

I think our current system of merging PRs to develop then making a release to master has some flaws to it.

1. In order to use Linked Issues when merging PRs, the PRs have to be merged to the default branch aka master. By merging them into develop first, Linked Issues aren't triggered and issues aren't closed when merged.
2. Our repo relies on some Actions that need to be merged into master for it to work (workflow_run for example). By limiting PRs into master only 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:

1. Rename master to stable-release
2. Rename develop to master
3. Change GitHub setting to point to develop as 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

[Panquesito7]

Good idea 👍 actually, we can keep the master branch as-is (with that name), and just change the default one to develop, and keep the GitHub Pages branch to master, which is the stable version. What do you think? 🙂

[Thomas-Boi]

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 master and not develop

[amacado]

1. Rename master to stable-release
2. Rename develop to master
3. Change GitHub setting to point to develop as the default branch.

When we would follow 1 and 2 there would be no develop branch for step 3 (since it's renamed). This confused me while reading it the first time. I suggest:

1. Rename master to stable (to not get confused by the new naming strategy of github regarding main branch)
2. Change GitHub setting to point to develop as the default branch
3. GitHub pages will be served trough stable

An issue could be that some people refer to the master branch 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 the master branch is "hard coded" in any actions/links. I'm not sure if GitHub auto-redirects a renamed branch (like they to with repository names).

In order to use Linked Issues when merging PRs, the PRs have to be merged to the default branch aka master. By merging them into develop first, Linked Issues aren't triggered and issues aren't closed when merged.

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 develop stage". 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 merged state. 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 in development stage and not been released yet.

According to this example I think it's not to bad to have no auto-close feature on the develop branch. This problem might be solved with some auto-labeling feature which applies a "currently in develop branch" or "released in vX.X.X" label to an issue.

[Thomas-Boi]

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 develop stage".
According to this example I think it's not to bad to have no auto-close feature on the develop branch. This problem might be solved with some auto-labeling feature which applies a "currently in develop branch" or "released in vX.X.X" label to an issue.

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]

I'll go with making a script that labels issues as being in develop