search

Kaszanas / SC2DatasetPreparator

MIT License
3 stars 3 forks source link

Default branch vs PRs vs stable branch #25

Open Ostrzyciel opened 6 months ago

Ostrzyciel commented 6 months ago

Currently the default branch is main, but it has really outdated code. The real main branch is dev. The thing is that when I submit a PR, it by default tries to make the PR to the default branch of the repository (which is main), which of course makes zero sense. As far as I can tell, GitHub does not allow to have the default PR branch to be different from the default branch – it is essentially the same.

OK, to the point: the usual GH convention is that main is the default branch for development and then you can create a stable branch (e.g., stable or 1.0) for stable releases. This way new contributors (1) see the newest code on the repo's homepage (2) see an up-to-date README (which can be important for e.g., licensing reasons) and (3) know where to contribute their code to.

I will not insist on this, but for me this kind of setup would make much much more sense on GitHub, where basically everybody else uses it. Alternatively, we can keep things as-is, but also put a lengthy explanation of branches, PRs, etc. in the README. For me it's easier to be like everybody else. Occam's razor.

Ostrzyciel commented 6 months ago

One more issue I've found with this approach: the dev branch has some PR and issue templates configured, but they are not used, as they aren't in the default branch (main).

Kaszanas commented 6 months ago

One more issue I've found with this approach: the dev branch has some PR and issue templates configured, but they are not used, as they aren't in the default branch (main).

Yeah, these templates were added in active development after initial release. My plan was to have them applicable from the next version.

As for the branch naming I had the convention that main is the stable branch dev has ongoing development, and feature branches are merged to dev and then in the end to main.

Ostrzyciel commented 6 months ago

Ok, whatever you prefer. I'm just saying that is not the convention usually used on GitHub (it's more common in corporate repos, I think) and because of that there are some UX snags, like what I pointed out above. If you are fine this, then please feel free to just close the issue.