Difference between revisions of "RepositoryStructure"
m |
(some updated for different proposed models) |
||
| Line 3: | Line 3: | ||
== Stable Releases == | == Stable Releases == | ||
These are the branches that are considered stable and ok to be used by everyone. | 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. | ||
* v3.2 (campaign2010) | Releases get even version numbers. | ||
* v3. | |||
* v3.2 (e.g. use the current campaign2010 for that) | |||
* v3.6 (e.g. use the current campaign2011 for that) | |||
* v4.0 | * v4.0 | ||
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/> | |||
'''Branch naming convention:''' ''v<major>.<even_minor>'' | |||
=== 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:''' ''development branch''<br/> | |||
'''Must merge back into:''' ''development branch''<br/> | |||
'''Branch naming convention:''' ''v<major>.<odd_minor>'' | |||
== Development branch == | == Development branch == | ||
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. | |||
Here we have come up with different models. | |||
== | === Master branch for development model === | ||
Use branch "master" for development. | |||
=== dev branch for development model === | |||
Like now the branch "dev" is used for development. In this case "master" would always point to the latest stable release. | |||
=== no permanent development branch === | |||
Another option could be to not have a permanent development branch at all, but instead immediately start with a new odd version branch after a release where feature branches would be merged into. | |||
== Feature branches == | == Feature branches == | ||
If a new feature is being implemented and is meant for people to test the | 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. For example these branches could have names like: | ||
* feature_state_interface | * feature_state_interface | ||
* feature_luftboot_support | * feature_luftboot_support | ||
* feature_spi_queues | * feature_spi_queues | ||
'''May branch off from:''' ''development branch''<br/> | |||
'''Must merge back into:''' ''development branch''<br/> | |||
'''Branch naming convention:''' ''feature_<description>'' | |||
Another option could be to name them according to the next preparation branch <major>.<odd_minor>_<feature_name>. | |||
== Hotfix 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: "v<major_nr>.<minor_nr>_fix_<description>". For example: | |||
* v4.0_fix_b2_v12_mag_signs | |||
'''May branch off from:''' ''stable branch''<br/> | |||
'''Must merge back into:''' ''stable branch''<br/> | |||
'''Branch naming convention:''' ''<major>.<even_minor>_fix_<description>'' | |||
== Old VS new repository structure == | == Old VS new repository structure == | ||
This section describes how the old structure will be changed to the new structure. | This section describes how the old structure will be changed to the new structure. | ||
Basically the current "dev" would become the release preparation branch (we can then delete 4.0_beta), the "locm3" branch would become the new development branch. | |||
* rename: dev -> v3.9 | |||
* rename: campaign2010 -> v3.4 | |||
* rename: campaign2011 -> v3.6 | |||
* rename: spi_driver -> feature_spi_driver (or v4.1_spi_driver) | |||
For the new development branch there are different options (as described above): | |||
#master for development: | |||
#* reset master to current locm3 | |||
#dev for development: | |||
#* reset dev -> locm3 | |||
* | #* master: reset to new v3.9 (even if it is not a release, and keep it on the release branches from there on)? | ||
* | |||
* | |||
Revision as of 13:58, 7 May 2012
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 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.
- v3.2 (e.g. use the current campaign2010 for that)
- v3.6 (e.g. use the current campaign2011 for that)
- v4.0
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>
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: development branch
Must merge back into: development branch
Branch naming convention: v<major>.<odd_minor>
Development branch
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.
Here we have come up with different models.
Master branch for development model
Use branch "master" for development.
dev branch for development model
Like now the branch "dev" is used for development. In this case "master" would always point to the latest stable release.
no permanent development branch
Another option could be to not have a permanent development branch at all, but instead immediately start with a new odd version branch after a release where feature branches would be merged into.
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. For example these branches could have names like:
- feature_state_interface
- feature_luftboot_support
- feature_spi_queues
May branch off from: development branch
Must merge back into: development branch
Branch naming convention: feature_<description>
Another option could be to name them according to the next preparation branch <major>.<odd_minor>_<feature_name>.
Hotfix 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: "v<major_nr>.<minor_nr>_fix_<description>". For example:
- v4.0_fix_b2_v12_mag_signs
May branch off from: stable branch
Must merge back into: stable branch
Branch naming convention: <major>.<even_minor>_fix_<description>
Old VS new repository structure
This section describes how the old structure will be changed to the new structure.
Basically the current "dev" would become the release preparation branch (we can then delete 4.0_beta), the "locm3" branch would become the new development branch.
- rename: dev -> v3.9
- rename: campaign2010 -> v3.4
- rename: campaign2011 -> v3.6
- rename: spi_driver -> feature_spi_driver (or v4.1_spi_driver)
For the new development branch there are different options (as described above):
- master for development:
- reset master to current locm3
- dev for development:
- reset dev -> locm3
- master: reset to new v3.9 (even if it is not a release, and keep it on the release branches from there on)?