RepositoryStructure - Revision history

Flixr at 12:53, 23 April 2015

2015-04-23T12:53:03Z

← Older revision		Revision as of 06:53, 23 April 2015
Line 10:		Line 10:
	Needs bench testing and careful flight testing on your end.		Needs bench testing and careful flight testing on your end.

	== ~~Release Preparation Branches ==~~		== Stable 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~~ ==

	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~~.		These are the branches that are considered stable and ok to be used by everyone.

	'''Releases get even version numbers.'''		'''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.
Line 40:		Line 30:
	'''Must merge back into:''' ''master''<br/>		'''Must merge back into:''' ''master''<br/>
	'''Branch naming convention:''' ''<feature_description>''		'''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 ==		== Hotfix branches ==

Flixr: remove very old info about dev branch

2015-04-23T12:45:08Z

remove very old info about dev branch

← Older revision		Revision as of 06:45, 23 April 2015
Line 8:		Line 8:
	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.		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.		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.
	~~<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 Branches ==
Line 54:		Line 53:

	* v4.0_fix_b2_v12_mag_signs		* v4.0_fix_b2_v12_mag_signs

	~~== Old VS new repository structure ==~~
	~~<span style="color:red">'''The branch "master" is now our development branch. There is no branch named "dev" anymore.'''</span>~~

	* 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.

Flixr: found workaround to display it as image with branch

2014-08-28T13:19:29Z

found workaround to display it as image with branch

← Older revision		Revision as of 07:19, 28 August 2014
Line 4:		Line 4:

	== Development branch (master) ==		== Development branch (master) ==
	<span class="plainlinks">[https://travis-ci.org/paparazzi/paparazzi https://travis-ci.org/paparazzi/paparazzi.png]</span>		<span class="plainlinks">[https://travis-ci.org/paparazzi/paparazzi https://travis-ci.org/paparazzi/paparazzi.png?branch=master,?.png]</span>

	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.		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.

Flixr: /* Development branch (master) */

2014-08-28T13:15:30Z

Development branch (master)

← Older revision		Revision as of 07:15, 28 August 2014
Line 4:		Line 4:

	== Development branch (master) ==		== Development branch (master) ==
	https://travis-ci.org/paparazzi/paparazzi.png		<span class="plainlinks">[https://travis-ci.org/paparazzi/paparazzi https://travis-ci.org/paparazzi/paparazzi.png]</span>

	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.		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.

Flixr: still can't figure out how to embed it with specifiying the branch like: https://travis-ci.org/paparazzi/paparazzi.png?branch=master

2014-08-28T13:13:22Z

still can't figure out how to embed it with specifiying the branch like: https://travis-ci.org/paparazzi/paparazzi.png?branch=master

← Older revision		Revision as of 07:13, 28 August 2014
Line 4:		Line 4:

	== Development branch (master) ==		== Development branch (master) ==
			https://travis-ci.org/paparazzi/paparazzi.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.		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.		It should at least compile, but can have untested new features. New features are being injected into this one from the feature branches.

Flixr at 11:50, 9 May 2012

2012-05-09T11:50:07Z

@@ Line 2: / Line 2: @@
 [[Image:RepositoryBranching.png|400px|thumb|Branching Model Diagram]]
 == 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.
 '''May branch off from:''' ''release preparation branch''<br/>
 '''Branch naming convention:''' ''v<major>.<even_minor>'', e.g. v4.0
 == 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.
-'''May branch off from:''' ''development branch''<br/>
-'''Must merge back into:''' ''development branch''<br/>
+'''May branch off from:''' ''master''<br/>
 '''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:
 '''May branch off from:''' ''stable branch''<br/>

Flixr at 00:35, 9 May 2012

2012-05-09T00:35:34Z

← Older revision		Revision as of 18:35, 8 May 2012
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.

	[[Image:RepositoryBranching.png\|400px\|thumb\|Branching Model Diagram]]		[[Image:RepositoryBranching.png\|400px\|thumb\|Branching Model Diagram]]

Esden at 23:30, 8 May 2012

2012-05-08T23:30:12Z

← Older revision		Revision as of 17:30, 8 May 2012
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 branches and which one is the right one for you.

			[[Image:RepositoryBranching.png\|400px\|thumb\|Branching Model Diagram]]

	== Stable Releases ==		== Stable Releases ==

Flixr: removed discussion stuff, describes final new branching model now

2012-05-08T22:48:07Z

removed discussion stuff, describes final new branching model now

← Older revision		Revision as of 16:48, 8 May 2012
Line 6:		Line 6:

	'''Releases get even version numbers.'''		'''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.		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>''		'''Branch naming convention:''' ''v<major>.<even_minor>'', e.g. v4.0

	=== Release Preparation Branches ===		=== Release Preparation Branches ===
Line 23:		Line 19:
	'''May branch off from:''' ''development branch''<br/>		'''May branch off from:''' ''development branch''<br/>
	'''Must merge back into:''' ''development branch''<br/>		'''Must merge back into:''' ''development branch''<br/>
	'''Branch naming convention:''' ''v<major>.<odd_minor>''		'''Branch naming convention:''' ''v<major>.<odd_minor>'', e.g. v3.9

	== Development branch ==		== 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.		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.		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~~.		<span style="color:red">'''The branch "master" is now our development branch. There is no branch named "dev" anymore.'''</span>

	~~=== 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.~~

	~~In this case we could keep master pointing to the latest stable release or not have any permanent branches at all (but this has quite a few drawbacks).~~

	~~=== Votes ===~~
	* no permanent development branch (less branches and obvious where development is being done atm) [[User:Esden\|Esden]] 21:10, 7 May 2012 (UTC)
	* any of the above, as long as we keep one branch named "master" (which would be either the latest stable or the development branch) [[User:Flixr\|flixr]] 21:18, 7 May 2012 (UTC)
	* keep "master" as latest stable. If possible, keep "dev" for development (I think it is better to have a single reference branch to start working on a new "feature" and merge it back) Gautier 8 May 2012
	* having master for the development and tags/branches as stable is how git usually is used (e.g. Linux), people would checkout a dedicated stable version [[User:Martinmm\|Martinmm]] 22:35, 8 May 2012 (UTC)
	== Feature branches ==		== Feature branches ==

Line 68:		Line 48:

	== Old VS new repository structure ==		== Old VS new repository structure ==
			<span style="color:red">'''The branch "master" is now our development branch. There is no branch named "dev" anymore.'''</span>

	~~This section describes how the old structure will be changed to the new structure.~~		* 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.
	~~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)~~

	~~Comment from Gautier (8 May 2012): actually, I like the names~~ "~~campaignXXXX~~" ~~or something similar~~ to ~~name~~ the ~~stable releases. It recalls that Paparazzi is supposed to be used for~~ "~~real~~" ~~applications~~, ~~it's not only a piece of software. But we can keep both numbers and names.~~

	~~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)?~~

Flixr: /* Feature branches */

2012-05-08T21:47:09Z

Feature branches

← Older revision		Revision as of 15:47, 8 May 2012
Line 53:		Line 53:
	'''May branch off from:''' ''development branch''<br/>		'''May branch off from:''' ''development branch''<br/>
	'''Must merge back into:''' ''development branch''<br/>		'''Must merge back into:''' ''development branch''<br/>
	'''Branch naming convention:''' ''~~feature_~~<~~description~~>''		'''Branch naming convention:''' ''<feature_description>''

	~~Another option could be to name them according to the next preparation branch <major>.<odd_minor>_<feature_name>.~~

	~~For example these branches could have names like:~~

	* feature_state_interface
	* feature_luftboot_support
	or
	* v4.1_spi_queues

	== Hotfix branches ==		== Hotfix branches ==