Consider Switching to Git Flow

Summary

The Duality repo currently uses a custom setup for its branches and workflow. To make it easier for new contributors to understand the process, consider adopting the widely used git flow model, or a variant of it.

Analysis

• This can be done entirely by renaming branches and updating docs in the wiki.
• Renaming a branch should be no big deal and not a breaking change for forked repos.
  • Branch off from the original branch using the new name.
  • Push the new branch to the repo.
  • Delete the old branch on the repo.
  • Fetch + Prune the local clone of the repo.
• Branches to be renamed:
  • master becomes develop
  • release becomes master
  • develop-3.0 becomes release/3.0
  • 1.x becomes archive/1.x
  • Any ongoing feature branch becomes feature/[3.0/]name-of-whatever
• Update the docs:
  • Development Cycle
  • Branch Descriptions
  • Make sure there’s a link it in the appropriate .github docs
• Deviations from standard git flow:
  • Using slashes for feature and release branch prefixes instead of hyphens.
  • Allow to directly merge smaller changes directly from develop to master, except for really big stuff.
  • Using archive branches for old major versions.
• Whether or not to switch to the new model is to be discussed.
  • Is there really a need to do this?
  • Does it make the development process easier or harder?

[BobGneu]

There are quite a few adaptations to GitFlow that seem to be inline with the goals you shared.

Maintaining multiple major versions is definitely an option, just not often done. Here is one such discussion.

[Barsonax]

2 years later and I would suggest its better to look at something like githubflow. Having a separate develop and master doesn’t give you any advantages but can cause some pesky merge conflicts. 2 long lived branches that represent the same history is bound to go wrong.

Releasing a new version should be done by creating a new tag. No need for complicated merges and this also makes it easy to see which versions where deployed in the past.

To support older versions we should have a separate branch for each older version we support. These branches are basically a master branch for their respective version. Bringing changes from a newer version to a old version should be done with cherrypicks.