Remove the "dev" branch and keep "main" as the development branch

The dev branch seems redundant. The only apparent benefit it has is that people can get the stable release via

git clone https://github.com/PMEAL/OpenPNM

We could keep “master” the development branch, and those who are interested in cloning the stable release via git can do

git clone --branch <stable_release_tag_name> https://github.com/PMEAL/OpenPNM

Not to mention that people mostly download OpenPNM via PyPI and more recently conda, which always have the stable release.

An minor benefit of working with master as the development branch is that mentioning issues in pull requests using the following keywords:

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

automatically closes the corresponding issue, which is certainly convenient.

[jgostick]

That’s perfect. We should update the VERSIONING.md document though. We were required to have this document by canarie. I’ll change this on the new examples_galore branch.

[ma-sadeghi]

We finally agreed to the following changes:

• Keep merging latest code to dev branch as usual
• Change the default branch from master to dev, which makes our GitHub landing page always up-to-date
• Create a new branch called release (optionally delete master altogether to avoid confusion)
• Merge dev onto release whenever we want to publish a minor/major/patch version
• Occasionally, when a major bug is found that needs an immediate patch release, and at the same time, we’re not yet ready to release what’s on dev, directly merge the hotfix PR onto release, and cherry pick (or merge back) the hotfix commit and merge back onto dev.
• Although the best practice remains that we avoid merging onto dev if a feature is not fully ready and therefore, the above case should ideally be an exception rather than a rule.
• In the future, if we find out that we don’t have that many “special” hotfixes, we can get rid of the release branch altogether.

@jgostick Does that sum it up?