As it seems to be some interest in contributing to LMNucleus, we need to have some structure on how contributions are handled. I don't have much experience in administering git repositories, but my suggestions are as follows:
As I have already accepted a pull request on the master branch, these commits will stay, but no further pull requests against the master branch will be accepted.
The already open pull requests against the master branch will be manually merged with the new 5.0 branch. Hopefully I will manage to do this without breaking anything, as my Git-fu is still weak.
I think this is reasonable. If you haven't yet, you might check out Atlassian's page on different workflows. What you've proposed sounds similar to their Feature Branch Workflow: https://www.atlassian.com/git/workflows … ure-branch — except you'll basically have one branch for 3.x and one for 5.x, correct?
There is also their more advanced Gitflow Workflow: https://www.atlassian.com/git/workflows … ow-gitflow
Personally, I like the idea of "master" being the latest stable beta code — merging in code from a "develop" branch once they've been alpha tested. Then, after successful beta testing (and whatever milestones you decide), a release is set up based on the appropriate commit in "master." I like this because end users should be downloading a release package rather than any specific branch, and beta testers can always checkout the "master" branch. It sounds like this is basically what you're describing, except instead of using "master" you'll have two branches for 3.x and 5.x. Would the "master" branch be the stable release version of 5.x, in that case?
It actually sounds like the Feature Branch Workflow together with a some of the Gitflow Workflow.
What kind of releases (beta/final) one choose to update the master branch with can depend on what kind repository forks/clones one would like to cater most. For betatesters would it be most convenient to have the betas in the master branch. But for people who want to do some personal adjustments to the latest version is it preferable to have the latest release in the master branch.
How one handles releases and the master branch can be anyway be adjusted later. I think I will dedicate the master branch for the current release for now.
This is how I see how the master branch will be updated: The 5.0 version will be developed in the 5.0 branch or temporary branches branched from the 5.0 branch. When the 5.0 version is ready to be released will the 5.0 branch be merged with the master branch. Any bugfixes for the 5.0 release version will be developed in the 5.0 branch, and merged with the master branch when released as 5.0.x. At some time will a branch for developing 5.1 be created from the 5.0 branch. Changes made to the 5.0 branch after the branching will be merged with the 5.1 branch when needed or at least when 5.0 versions is released.