[meta] Collaborator discussion

[martinrieder]

@kvid @formatc1702 I see so many feature requests and I would even have some more ideas... It seems overwhelming and possibly requires some priorisation or roadmapping. I suggest that one of you starts an issue for discussion on this topic. Similar to #365, there should be some PR about the next major release already. I do not want to take ownership of it, though. ;)

It is not obvious, which PRs should be based on master or dev. I noticed that PR #357 is based on the dev branch. The others are merged into a release branch that is directly based on master. If I am to prepare some PR, what shall be the base?

[kvid]

I use #365 to collect simple bugfixes to be released soon, and I have chosen to base such PRs on master to enable other PRs (not part of the upcoming bugfix release) being based on dev in parallel. The next PR to be merged into dev is #251, but I've been too busy lately to look into that yet.

However, it's normally trivial to rebase a PR branch from dev to master or vice versa (unless the amount of change conflicts is huge) if priorities are changed. We are all free to argue for which PRs to include in a release, and if you feel e.g. PR #357 is important to release before a future v0.5, then please describe your reasons for that in a comment. 😃

Normally, I recommend basing a new PR on dev, but if it's a bugfix or other minor change with high priority, then you probably should argue for basing it on master.

[martinrieder]

@kvid wrote:

I use #365 to collect simple bugfixes to be released soon, and I have chosen to base such PRs on master to enable other PRs (not part of the upcoming bugfix release) being based on dev in parallel. The next PR to be merged into dev is #251, but I've been too busy lately to look into that yet.

Dito. I get the impression, #251 would definitely demand an 0.5 release branch or even a major step to 1.0... I would love to see semantic-release in action by then. There is a python-specific version called python-semantic-release...

We are all free to argue for which PRs to include in a release, and if you feel e.g. PR #357 is important to release before a future v0.5, then please describe your reasons for that in a comment. 😃

That is the reason why Semantic Versioning states clear rules and leaves out the personal feelings. If we were to follow these, #357 is a feature that would be part of 0.5.

Normally, I recommend basing a new PR on dev, but if it's a bugfix or other minor change with high priority, then you probably should argue for basing it on master.

There is another argument for basing it on master in the GitHub Docs about tracking issues and PRs:

The special keywords in a pull request description are interpreted when the pull request targets the repository's default branch. However, if the PR's base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch.

Note that I do not intend to influence the way that you have been working on this project. I am just giving hints on what could be improved. As long as you can handle things manually and there is no disagreement amongst the collaborators, just keep going without semantic-release. It simplifies and automates some chores, but it also adds dependencies, complexity and thereby limits the freedom that an innovative project needs in early stages!

My actual intent was only to ask for a list of feature priorities for the next release, possibly discussed in a dedicated issue! If you think that this issue is the right place to discuss this, then I am also fine with it.

EDIT: I found this https://github.com/wireviz/WireViz/issues/320#issuecomment-1679320770 by coincidence, asking for help on untangling #251 commits.