Difference between revisions of "RepositoryStructure"

From PaparazziUAV
Jump to navigation Jump to search
(Created page with "'''Repository Structure''' Refers to the way Paparazzi is naming the branches and which one is the right one for you. == Stable Releases == These are the branches that are cons…")
 
 
(20 intermediate revisions by 5 users not shown)
Line 1: Line 1:
'''Repository Structure''' Refers to the way Paparazzi is naming the branches and which one is the right one for you.
'''Repository Structure''' Refers to the way Paparazzi is naming the [[Git]] branches and which one is the right one for you.


== Stable Releases ==
[[Image:RepositoryBranching.png|400px|thumb|Branching Model Diagram]]


These are the branches that are considered stable and ok to be used by everyone. The structure is "paparazzi<nr>".
== Development branch (master) ==
<span class="plainlinks">[https://travis-ci.org/paparazzi/paparazzi https://travis-ci.org/paparazzi/paparazzi.png?branch=master,?.png]</span>


* paparazzi2
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.
* paparazzi3
It should at least compile, but can have untested new features. New features are being injected into this one from the feature branches.
* paparazzi4
Needs bench testing and careful flight testing on your end.


If you clone the repository directly from GitHub the newest stable release will end up in your working directory.
== Stable branches ==
 
These are the branches that are considered stable and ok to be used by everyone.
 
'''Releases get even minor version numbers.'''


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.


== Development branch ==


The development branch is always called "dev". This is the branch wehre new features are being implemented.
'''May branch off from:''' ''release preparation branch''<br/>
'''Branch naming convention:''' ''v<major>.<even_minor>'', e.g. v4.0


== Bugfix branches ==
== Feature branches ==


If there are bugfixes to certain stable branches that need to be tested before they get merged into stable they get their own branches of the structure: "p<nr>fix_<description>". For example:
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.


* p3fix_b2_v12_mag_signs


== Feature branches ==
'''May branch off from:''' ''master''<br/>
'''Must merge back into:''' ''master''<br/>
'''Branch naming convention:''' ''<feature_description>''
 
== 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
 
== Hotfix branches ==


If a new feature is being implemented and is meant for people to test the "dev" branch is being copied into "feature_<description>" and after the implementation of the new feature is completed those branches get merged with "dev" again. For example these branches could have names like:
If there are bugfixes that need to be tested before they get applied/merged to a stable release they get their own (temporary) branch:


* feature_state_interface
* feature_luftboot_support
* feature_spi_queues


== Old VS new repository structure ==
'''May branch off from:''' ''stable branch''<br/>
'''Must merge back into:''' ''stable branch''<br/>
'''Branch naming convention:''' ''<major>.<even_minor>_fix_<description>''


This section describes how the old structure will be changed to the new structure. These are the intended branch renames and actions as of 2012/April/25
For example:


* rename: master -> paparazzi3
* v4.0_fix_b2_v12_mag_signs
* Two options here
** rename: 4.0_beta -> paparazzi4 and delete: dev
** rename: dev -> paparazzi4 and delete: 4.0_beta
* merge: dev_i2c -> paparazzi4
* rename: locm3 -> dev
* rename: spi_driver -> feature_spi_driver
* rename: campaign2010 -> paparazzi1
* rename: campaign2011 -> paparazzi2
* rename: b2_v12_mag_signs -> p3_fix_b2_v12_mag_signs
* rename: quadshot_integration -> feature_transitioning_aircraft_support
* rename: new-state-interface -> feature_new-state-interface

Latest revision as of 06:53, 23 April 2015

Repository Structure Refers to the way Paparazzi is naming the Git branches and which one is the right one for you.

Branching Model Diagram

Development branch (master)

paparazzi.png?branch=master,?.png

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. Needs bench testing and careful flight testing on your end.

Stable branches

These are the branches that are considered stable and ok to be used by everyone.

Releases get even minor 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>

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

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