Talk:Branching and Version Control - Revision history

Howetuft: /* [CodeHD][26-08-31] First round of commenting: */

2026-09-01T04:46:03Z

[CodeHD][26-08-31] First round of commenting:

← Older revision		Revision as of 06:46, 1 September 2026
Line 1:		Line 1:
	= [CodeHD][26-08-31] First round of commenting: =		= [CodeHD][26-08-31] - First round of commenting: =
	* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.		* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.
	* In terms of the suggested branching: Previously we had talked about different concepts.		* In terms of the suggested branching: Previously we had talked about different concepts.

Howetuft: /* [Howetuft] */

2026-09-01T04:45:04Z

[Howetuft]

← Older revision		Revision as of 06:45, 1 September 2026
Line 7:		Line 7:
	* On long lived branches, your speak of "merging main regularly". I suppose this is supposed to say "rebase"? Otherwise I would expect extra trouble when we work on multiple long-lived branches in parallel which will be merged at different times.		* On long lived branches, your speak of "merging main regularly". I suppose this is supposed to say "rebase"? Otherwise I would expect extra trouble when we work on multiple long-lived branches in parallel which will be merged at different times.

	= [Howetuft] =		= [Howetuft][26-09-01] =

	== Building the Proposal ==		== Building the Proposal ==

Howetuft: /* [CodeHD] 26-08-31 - First round of commenting: */

2026-09-01T04:44:45Z

[CodeHD] 26-08-31 - First round of commenting:

← Older revision		Revision as of 06:44, 1 September 2026
Line 1:		Line 1:
	= [CodeHD] 26-08-31 - First round of commenting: =		= [CodeHD][26-08-31] First round of commenting: =
	* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.		* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.
	* In terms of the suggested branching: Previously we had talked about different concepts.		* In terms of the suggested branching: Previously we had talked about different concepts.

Howetuft: /* [CodeHD] First round of commenting: */

2026-09-01T04:41:34Z

[CodeHD] First round of commenting:

← Older revision		Revision as of 06:41, 1 September 2026
Line 1:		Line 1:
	= [CodeHD] First round of commenting: =		= [CodeHD] 26-08-31 - First round of commenting: =
	* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.		* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.
	* In terms of the suggested branching: Previously we had talked about different concepts.		* In terms of the suggested branching: Previously we had talked about different concepts.

Howetuft: /* [Howetuft] */

2026-09-01T04:38:24Z

[Howetuft]

← Older revision		Revision as of 06:38, 1 September 2026
Line 15:		Line 15:

	I tried to take into account the points we discussed, and I also consulted an AI.		I tried to take into account the points we discussed, and I also consulted an AI.
	After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/. ~~That~~ may be the first point of discussion.		After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/.

			The strategy is very similar to what we do, as evidenced by the many points of agreement you've pointed out. However, it has an overall coherence that may cause it to differ slightly in certain details from what we had discussed.

			The choice of the underlying strategy may be the first point of discussion.

	== Detailing ==		== Detailing ==

	Once I’ve adopted this approach, I've highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, ~~though—the~~ release process is missing, and it’s crucial. I’ll add it.		Once I’ve adopted this approach, I've highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, though — the release process is missing, and it’s crucial. I’ll add it.

	== Typos ==		== Typos ==

	Finally, you're right, “merging main regularly” in working branches is incorrect; of course, we need to <i>rebase</i> the working branch onto main.		Finally, you're right, “merging main regularly” in working branches is incorrect; of course, we need to <i>rebase</i> the working branch onto main.

Howetuft: /* [Howetuft] */

2026-09-01T04:34:02Z

[Howetuft]

← Older revision		Revision as of 06:34, 1 September 2026
Line 8:		Line 8:

	= [Howetuft] =		= [Howetuft] =

			== Building the Proposal ==
	Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:		Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:

Line 14:		Line 16:
	I tried to take into account the points we discussed, and I also consulted an AI.		I tried to take into account the points we discussed, and I also consulted an AI.
	After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/. That may be the first point of discussion.		After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/. That may be the first point of discussion.

			== Detailing ==

	Once I’ve adopted this approach, I've highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, though—the release process is missing, and it’s crucial. I’ll add it.		Once I’ve adopted this approach, I've highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, though—the release process is missing, and it’s crucial. I’ll add it.

	Finally, “merging main regularly” is incorrect; of course, ~~you~~ need to rebase the working branch onto main.		== Typos ==

			Finally, you're right, “merging main regularly” in working branches is incorrect; of course, we need to <i>rebase</i> the working branch onto main.

Howetuft: /* [Howetuft] */

2026-09-01T04:31:44Z

[Howetuft]

← Older revision		Revision as of 06:31, 1 September 2026
Line 10:		Line 10:
	Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:		Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:

	To arrive at this proposal, I conducted as comprehensive a review as possible of the various standard strategies that exist, so as not to reinvent the wheel (here, for instance: https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh)~~. I tried to take into account the points we discussed, and I also consulted an AI.~~		To arrive at this proposal, I conducted as comprehensive a review as possible of the various standard strategies that exist, so as not to reinvent the wheel (here, for instance: https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh).
	After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/.

	I’ve adopted this approach ~~and~~ highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, though—the release process is missing, and it’s crucial. I’ll add it.		I tried to take into account the points we discussed, and I also consulted an AI.
			After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/. That may be the first point of discussion.

			Once I’ve adopted this approach, I've highlighted a few key points, though not all of them (since the specification is quite extensive). You’re right, though—the release process is missing, and it’s crucial. I’ll add it.

	Finally, “merging main regularly” is incorrect; of course, you need to rebase the working branch onto main.		Finally, “merging main regularly” is incorrect; of course, you need to rebase the working branch onto main.

Howetuft: /* [Howetuft] */

2026-09-01T04:30:26Z

[Howetuft]

← Older revision		Revision as of 06:30, 1 September 2026
Line 10:		Line 10:
	Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:		Since you rightly point out that some points from our preliminary discussions may not have been included verbatim here, just a quick note on the method:

	To arrive at this proposal, I conducted as comprehensive a review as possible of the various standard strategies that exist, so as not to reinvent the wheel. I tried to take into account the points we discussed, and I also consulted an AI.		To arrive at this proposal, I conducted as comprehensive a review as possible of the various standard strategies that exist, so as not to reinvent the wheel (here, for instance: https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh). I tried to take into account the points we discussed, and I also consulted an AI.
	After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/.		After all that, what seems to best fit our parameters—particularly team size, the emphasis on bug fixing over long-term features, etc.—is Trunk-Based Development: https://trunkbaseddevelopment.com/.

Howetuft at 04:29, 1 September 2026

2026-09-01T04:29:22Z

@@ Line 1: / Line 1: @@
-[CodeHD] First round of commenting:
+= [CodeHD] First round of commenting: =
 * Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.
 * In terms of the suggested branching: Previously we had talked about different concepts.
@@ Line 6: / Line 6: @@
 ** I am fine with the desciption of main. Essentially, it would remain as-is, i.e. the default branch on GitHub protected against force-push.
 * On long lived branches, your speak of "merging main regularly". I suppose this is supposed to say "rebase"? Otherwise I would expect extra trouble when we work on multiple long-lived branches in parallel which will be merged at different times.

CodeHD: create discussion

2026-08-31T20:34:50Z

create discussion

New page

[CodeHD] First round of commenting:
* Preliminary considerations look good to me. Not sure the aspects about PyPI will/should really matter in the end, but no harm done in writing them down.
* In terms of the suggested branching: Previously we had talked about different concepts.
** what remains identical/similar is having branches like feature/*, etc. In terms of actual branch names, I don't personally care. "Chore" I did not see in guides before, we should add some descriptions of purposes.
** Different is that we previously talked about separate release preparation branches. I think release processes are still missing as a general category.
** I am fine with the desciption of main. Essentially, it would remain as-is, i.e. the default branch on GitHub protected against force-push.
* On long lived branches, your speak of "merging main regularly". I suppose this is supposed to say "rebase"? Otherwise I would expect extra trouble when we work on multiple long-lived branches in parallel which will be merged at different times.