Git repository organization



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:

  • The master branch is reserved for the current release. Changes to the master branch is merged from development branches when the the version is released.
  • All development is done in branches. Pull requests for the master branch will not be accepted.
  • Have one branch for the 3.x code line. This branch is added at the 3.66 release version, and only bugfixes for 3.66 will be accepted for this branch.
  • Have one branch for a new 5.0 code line for any code that isn't bugfixes for 3.66. Going for a 5.0 version to avoid any confusion with the never finished 4.0 release of Nucleus.
  • Pull requests that leave LMNucleus in a non functional state will not be accepted, unless the pull request is against a work in progress branch dedicated for the change.
  • Pull requests with changes that break backward compatibility will not be accepted.

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. smile


New member

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: … 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: … 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. smile

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.