Difference between revisions of "RepositoryStructure"
m |
|||
| Line 2: | Line 2: | ||
[[Image:RepositoryBranching.png|400px|thumb|Branching Model Diagram]] | [[Image:RepositoryBranching.png|400px|thumb|Branching Model Diagram]] | ||
== Development branch (master) == | |||
A permanent branch where current the development is based on. For users wanting to test the the bleeding edge, this is the one to use. | |||
It should at least compile, but can have untested new features. New features are being injected into this one from the feature branches. | |||
<span style="color:red">'''The branch "master" is now our development branch. There is no branch named "dev" anymore.'''</span> | |||
== Release Preparation Branches == | |||
Release preparation is done in branches with '''odd version numbers'''. When it is ready the branch is renamed to the next even number. | |||
So e.g. stabilization and testing is done in v4.1 and then renamed to v4.2 (and tagged) on release. | |||
'''May branch off from:''' ''master''<br/> | |||
'''Must merge back into:''' ''master'', ''next stable branch''<br/> | |||
'''Branch naming convention:''' ''v<major>.<odd_minor>'', e.g. v3.9 | |||
== Stable Releases == | == Stable Releases == | ||
| Line 10: | Line 26: | ||
The only commits that go into those branches are only bugfixes. No new feature commits are being done directly to those. | The only commits that go into those branches are only bugfixes. No new feature commits are being done directly to those. | ||
'''May branch off from:''' ''release preparation branch''<br/> | '''May branch off from:''' ''release preparation branch''<br/> | ||
'''Branch naming convention:''' ''v<major>.<even_minor>'', e.g. v4.0 | '''Branch naming convention:''' ''v<major>.<even_minor>'', e.g. v4.0 | ||
== Feature branches == | == Feature branches == | ||
| Line 33: | Line 35: | ||
If a bigger new feature is being implemented and is meant for people to test the development branch is being copied into "feature_<description>" and after the implementation of the new feature is completed those branches get merged back into the development branch again. | If a bigger new feature is being implemented and is meant for people to test the development branch is being copied into "feature_<description>" and after the implementation of the new feature is completed those branches get merged back into the development branch again. | ||
'''May branch off from:''' '' | |||
'''Must merge back into:''' '' | '''May branch off from:''' ''master''<br/> | ||
'''Must merge back into:''' ''master''<br/> | |||
'''Branch naming convention:''' ''<feature_description>'' | '''Branch naming convention:''' ''<feature_description>'' | ||
| Line 40: | Line 43: | ||
If there are bugfixes that need to be tested before they get applied/merged to a stable release they get their own (temporary) branch: | If there are bugfixes that need to be tested before they get applied/merged to a stable release they get their own (temporary) branch: | ||
'''May branch off from:''' ''stable branch''<br/> | '''May branch off from:''' ''stable branch''<br/> | ||
Revision as of 04:50, 9 May 2012
Repository Structure Refers to the way Paparazzi is naming the Git branches and which one is the right one for you.
Development branch (master)
A permanent branch where current the development is based on. For users wanting to test the the bleeding edge, this is the one to use. It should at least compile, but can have untested new features. New features are being injected into this one from the feature branches.
The branch "master" is now our development branch. There is no branch named "dev" anymore.
Release Preparation Branches
Release preparation is done in branches with odd version numbers. When it is ready the branch is renamed to the next even number. So e.g. stabilization and testing is done in v4.1 and then renamed to v4.2 (and tagged) on release.
May branch off from: master
Must merge back into: master, next stable branch
Branch naming convention: v<major>.<odd_minor>, e.g. v3.9
Stable Releases
These are the branches that are considered stable and ok to be used by everyone. The default branch on github (the one you get when cloning the repository) will always be set to the latest stable release.
Releases get even version numbers.
The only commits that go into those branches are only bugfixes. No new feature commits are being done directly to those.
May branch off from: release preparation branch
Branch naming convention: v<major>.<even_minor>, e.g. v4.0
Feature branches
If a bigger new feature is being implemented and is meant for people to test the development branch is being copied into "feature_<description>" and after the implementation of the new feature is completed those branches get merged back into the development branch again.
May branch off from: master
Must merge back into: master
Branch naming convention: <feature_description>
Hotfix branches
If there are bugfixes that need to be tested before they get applied/merged to a stable release they get their own (temporary) branch:
May branch off from: stable branch
Must merge back into: stable branch
Branch naming convention: <major>.<even_minor>_fix_<description>
For example:
- v4.0_fix_b2_v12_mag_signs
Old VS new repository structure
The branch "master" is now our development branch. There is no branch named "dev" anymore.
- The "dev" branch was renamed to the release preparation branch "v3.9".
- "master" was reset to the previous "locm3" branch, where development will happen now with libopencm3 for the STM32 architecture.