Skip to content
Snippets Groups Projects
Commit efe42f65 authored by Daniel Jaschke's avatar Daniel Jaschke
Browse files

Merge branch 'feature/#5_master_develop' into 'develop'

Merge strategies for master/develop

See merge request quantum_tea_internal/quantum_tea_internal!11
parents 294ef4ed 18565d0f
No related branches found
No related tags found
No related merge requests found
Pipeline #102025 passed
......@@ -5,7 +5,7 @@ qiv = python_requires('qtea_conan_helpers/0.1.4@quantumteabag/testing')
class QuantumTeaConanFile(ConanFile):
name = 'quantum_tea'
version = '0.0.5'
version = '0.0.6'
license = ''
author = ', '.join([
'Marco Ballarin',
......
# Merging strategies
All repositories come with a master and develop branch.
The master branch is a more stable version of the code as it has been
around for longer while the develop branch has more recent features.
Any changes are implemented on feature branches
(their name starts with feature/...) or bugfix branches
(their name starts with bugfix/...). Depending on the repository:
1. Neither master nor develop are mirrored to public repository;
2. master is mirrored to a public repository, but develop is not;
3. both master and develop are mirrored to a public repository.
## Doing the review
As a reviewer, point out to the assignee if one of the following
conditions is true. Then, the developer can double-check if that
is what he wants to do.
- a feature branch is merged toward master;
- a hotfix branch is merged towards develop to be sure the bug
does not exist on master (unless it is the second pull request);
- Version number decrease (can never happen)
- Major or minor increases for hotfixes / bugfixes (especially if
the major.minor then matches the one on develop!)
- Major or minor increases for feature, but the feature does not
look like it breaks backwards compatability.
## Branching and merging when both master and develop
For the packages where both master and develop are present, the merging
strategy can be complex. We thus divide the discussion in three different
cases.
We consider master and develop as diverged if master and develop differ
in the major or minor version.
### Master and develop are not diverging
This is the easiest case, when both master and develop sit at the same commit
or the master branch could be fast-forwarded to develop.
It might happen in the beginning, but it is rather complex that it will happen
in other cases.
The procedure is the following:
1. Merge the bugfix/feature to develop, upgrading the version number.
2. [optional] Locally merge develop into master.
3. Disable the protection for pushing master for the mantainers.
4. [optional] Push master.
5. Enable again the protection for the master branch.
2 and 4 are marked as optional since if master is behind develop,
there is no need to update it now.
### New feature
Develop the new feature branching from the **develop** branch.
Don't put hotfixes into feature branches! Otherwise the master might be without
the hotfix for a long time. Merge the feature branch in develop, upgrading the
minor minor version, i.e. from `0.2.0` to `0.2.1`.
### Hotfix when master and develop are on different commits
Let's suppose that the version on master is the `0.1.0`, while the version
on develop is the `0.2.0`
1. Start the branch from **master**, not from **develop**.
Update the version number for master from `0.1.0` to `0.1.1`.
The branch name should be `bugfix/#n_name` where `#n` is the number of the
issue to which the hotfix is connected. If no issue is available for the hotfix,
just call the branch `bugfix/name`.
2. Merge the branch to master, disabling the "automatically delete branch on merge"
flag. The new master is the **stable package**.
3. Do a new commit, which is just a version bump to `0.2.1`.
4. Merge the branch to develop and delete the merged branch. The new develop is the
**testing** package
### Updating master to the current develop
Let's suppose that the version on master is the `0.1.x`, while the version
on develop is the `0.2.4`. We are finally sure that the develop branch is
stable, and thus we want to have all the new features into master.
1. Start the branch from **develop**, not from **master**.
2. Update the version number from `0.2.4` to `0.2.5` and
merge to master. The master branch passed from version `0.1.x` to `0.2.5`.
Do not delete the merged branch, since it will be used again in the next step.
3. Update the minor version number, from `0.2.5` to `0.3.0` and merge to develop.
Notice that after each merge of develop into master, the minor version of the
former (develop) should increase.
......@@ -20,6 +20,7 @@ In this document we will follow this logic process:
chapters/fortran
chapters/general
chapters/merge_strategies
chapters/dependency_graph
Dependency Graph
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment