Branching and Version Control - Revision history

Howetuft: /* Strategy */

2026-10-05T03:43:09Z

Strategy

← Older revision		Revision as of 05:43, 5 October 2026
Line 4:		Line 4:


	= Strategy =		= General Strategy =

	Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.		Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.

Howetuft at 03:42, 5 October 2026

2026-10-05T03:42:35Z

← Older revision		Revision as of 05:42, 5 October 2026
Line 27:		Line 27:
	* LuxCore		* LuxCore
	* BlendLuxCore		* BlendLuxCore

			= Details =

	== Main branch ==		== Main branch ==
Line 112:		Line 114:
	* In a weekly build: run extensive tests to ensure non-regression.		* In a weekly build: run extensive tests to ensure non-regression.

	= Appendix: A few considerations that oriented our choice =		= Appendices =

			== Appendix A: A few considerations that oriented our choice ==

	* We are a very small core team. Branch strategy should be light and agile.		* We are a very small core team. Branch strategy should be light and agile.

Howetuft: /* Strategy */

2026-10-05T03:39:48Z

Strategy

← Older revision		Revision as of 05:39, 5 October 2026
Line 7:		Line 7:

	Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.		Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.


	We rely on <b>a <code>main</code> branch, always stable, always releasable.</b>		We rely on <b>a <code>main</code> branch, always stable, always releasable.</b>


	This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b>		This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b>


	<pre>		<pre>

Howetuft: /* Strategy */

2026-10-05T03:38:20Z

Strategy

← Older revision		Revision as of 05:38, 5 October 2026
Line 8:		Line 8:
	Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.		Our strategy is inspired by <i>Trunk-Based Development</i> (TBD), as described here: https://trunkbaseddevelopment.com/.

	We rely on <b>a <code>main</code> branch, always stable, always releasable.</b> This branch is "the Single Source of Truth" where all development happens.		We rely on <b>a <code>main</code> branch, always stable, always releasable.</b>

			This <code>main</code> branch is <b>"the Single Source of Truth" where all development happens.</b>

	<pre>		<pre>

Howetuft at 03:37, 5 October 2026

2026-10-05T03:37:10Z

@@ Line 2: / Line 2: @@
 = Strategy =
@@ Line 113: / Line 106: @@
 * In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.
 * In a weekly build: run extensive tests to ensure non-regression.

Howetuft: /* Release process */

2026-09-06T04:31:26Z

Release process

← Older revision		Revision as of 06:31, 6 September 2026
Line 90:		Line 90:


	The golden rule is that <b>the release branch “should not receive continued development work”.</b>. Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.		The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.

	Release branches are allowed to practice cherry-picking ~~and history rewriting~~, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.		Release branches are allowed to practice cherry-picking, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.

	In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.		In case of bug in release, the best practice is to reproduce the bug on the <code>main</code>, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.

Howetuft: /* Release process */

2026-09-06T04:29:52Z

Release process

← Older revision		Revision as of 06:29, 6 September 2026
Line 87:		Line 87:
	That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.		That's why release process should be prepared on a <code>release/X.Y</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.

			Please note that we create release branches only for major.minor, not for patches; that is, versions X.Y.0, X.Y.1, etc., will be hosted on the same <code>release/X.Y</code> branch.

	The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers ~~should~~ not commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.
			The golden rule is that <b>the release branch “should not receive continued development work”.</b>. Developers are not allowed to commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed yet.

	Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.		Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.

Howetuft: /* Release process */

2026-09-06T04:18:37Z

Release process

← Older revision		Revision as of 06:18, 6 September 2026
Line 88:		Line 88:


	The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch~~. Developers~~ only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.		The golden rule is that <b>the release branch “should not receive continued development work”.</b> Developers should not commit to release branch: developers only commit to <code>main</code>. Thus, release process is not blocking and post-release development can go on even if release has not been completed.

	Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.		Release branches are allowed to practice cherry-picking and history rewriting, thus making possible to release only a sub-scope of the features present in <code>main</code>, for instance by branching before HEAD, and also to release bug fixes.

Howetuft: /* Continuous integration */

2026-09-06T04:17:48Z

Continuous integration

← Older revision		Revision as of 06:17, 6 September 2026
Line 109:		Line 109:
	== Continuous integration ==		== Continuous integration ==
	WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:		WIth a stable, releasable <code>main</code>, continuous integration can be applied at least on two events:
	* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and ~~releasabiloty~~ are kept.		* In PR (and push): run minimal tests (buildability & simple runtime tests) to ensure stability and releasability are kept.
	* In a weekly build: run extensive tests to ensure non-regression.		* In a weekly build: run extensive tests to ensure non-regression.

Howetuft: /* Branch naming */

2026-09-06T04:17:23Z

Branch naming

← Older revision		Revision as of 06:17, 6 September 2026
Line 105:		Line 105:
	* <code>fix/*</code> : for bug fixing		* <code>fix/*</code> : for bug fixing
	* <code>refactor/*</code> : for code refactoring		* <code>refactor/*</code> : for code refactoring
	* <code>release/X.Y.Z</code> : for new release		* <code>release/X.Y</code> : for new release

	== Continuous integration ==		== Continuous integration ==