Branching and Version Control - Revision history

Howetuft: /* Release process */

2026-09-02T01:52:32Z

Release process

← Older revision		Revision as of 03:52, 2 September 2026
Line 85:		Line 85:
	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>, ~~but~~ 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.

	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-02T01:51:05Z

Release process

← Older revision		Revision as of 03:51, 2 September 2026
Line 83:		Line 83:
	That's why release process should be prepared on a <code>release/X.Y.Z</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.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.

	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>. ~~As a counterpart~~, 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>, but 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: /* Branch naming */

2026-09-02T01:35:23Z

Branch naming

← Older revision		Revision as of 03:35, 2 September 2026
Line 94:		Line 94:

	Available types are:		Available types are:
	* <code>feature/*</code>		* <code>feature/*</code> : for new feature development
	* <code>fix/*</code>		* <code>fix/*</code> : for bug fixing
	* <code>refactor/*</code>		* <code>refactor/*</code> : for code refactoring
	* <code>release/X.Y.Z</code>		* <code>release/X.Y.Z</code> : for new release

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

Howetuft: /* Main branch */

2026-09-01T11:29:37Z

Main branch

← Older revision		Revision as of 13:29, 1 September 2026
Line 38:		Line 38:
	** Straight push is discouraged (though not totally forbidden, see below)		** Straight push is discouraged (though not totally forbidden, see below)
	** PRs must ensure a good level of completeness		** PRs must ensure a good level of completeness
	* Releases are built from the <code>main</code> branch~~. Release points are tags of <code>main</code>~~.		* Releases are built from the <code>main</code> branch.
	* Releases are immutable (PyPi)		* Releases are immutable (PyPi)
	* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.		* Every piece of work gets a dedicated branch: <code>feature/login-form</code>, <code>fix/cart-bug</code>, <code>chore/upgrade-deps</code> etc.

Howetuft: /* Preliminary considerations */

2026-09-01T06:13:15Z

Preliminary considerations

← Older revision		Revision as of 08:13, 1 September 2026
Line 10:		Line 10:
	* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.		* Our needs vary depending on whether we are in feature development phases or release and stabilization phases.
	* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time).		* Our availability varies, which means that some development tasks may take time (and the related development branches may remain active for a long time).
	* We are also dependent from other environments: in particular, ~~wdeploy~~ on PyPi, where releases are immutable		* We are also dependent from other environments: in particular, we deploy on PyPi, where releases are immutable

	= Strategy =		= Strategy =

Howetuft: /* Strategy */

2026-09-01T06:12:57Z

Strategy

← Older revision		Revision as of 08:12, 1 September 2026
Line 14:		Line 14:
	= Strategy =		= Strategy =

	Our strategy is inspired by <b>Trunk-Based Development</b> (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 branch is "the Single Source of Truth" where all development happens.

Howetuft: /* Strategy */

2026-09-01T06:12:42Z

Strategy

← Older revision		Revision as of 08:12, 1 September 2026
Line 14:		Line 14:
	= Strategy =		= Strategy =

	Our strategy is inspired by Trunk-Based Development (TBD), as described here: https://trunkbaseddevelopment.com/.		Our strategy is inspired by <b>Trunk-Based Development</b> (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 branch is "the Single Source of Truth" where all development happens.

Howetuft: /* Release process */

2026-09-01T05:22:15Z

Release process

← Older revision		Revision as of 07:22, 1 September 2026
Line 81:		Line 81:
	In a more general way, however, there is often a need for release branch, due to bug-fixing.		In a more general way, however, there is often a need for release branch, due to bug-fixing.

	That's why release process should be prepared on a <code>release/X.Y.Z</code> branch, cut from <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.Z</code> branch, cut from <code>main</code>. The branch cut itself is a commit in <code>main</code>.

	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>. As a counterpart, 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>. As a counterpart, release process is not blocking and post-release development can go on even if release has not been completed.

	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-01T05:20:27Z

Release process

← Older revision		Revision as of 07:20, 1 September 2026
Line 74:		Line 74:
	== Release process ==		== Release process ==
	The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.		The release process should be made comfortable by the fact that the <code>main</code> branch is required to be stable and release-ready at all times.
	Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</~~main~~>.		Thanks to the CI, we should have some assurance regarding buildability and the absence of regressions for the code in <code>main</code>.
	Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.		Therefore, in theory, once we decide to create a release, it should be possible to do so directly from the latest commit in the <code>main</code> branch.

Howetuft: /* Release process */

2026-09-01T05:20:08Z

Release process

← Older revision		Revision as of 07:20, 1 September 2026
Line 89:		Line 89:

	For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/		For more details, see here: https://trunkbaseddevelopment.com/branch-for-release/


	== Branch naming ==		== Branch naming ==