[fpc-devel] [RFC] Modernising the FPC Release Process -- Proposal for Review

[Graeme Geldenhuys]

On Friday, 17 April 2026 15:21:08 BST Martin Frb via fpc-devel wrote:
> If I do my own commits (even If it was decided that every change, even
> single commits changes would go through a branch), then I would want to
> merge those branches locally.
> Going to the web interface requires me to involve an additional tool,
> switching to my browser, needing my browser to go to another tab,  ...
> It may just be a few clicks. Its still less if I do it locally.

Gitlab is just another tool. Yes, the FPC team chose it years ago - they must
have had specific reasons. But the same workflow can be done without GitLab,
by using "pure git" alone.

Here are the three most effective ways to recreate that workflow using pure Git.

1. Unique Tag Names (The "Suffix" Method)

You give each merge commit (or single commit) its own unique tag within a 
namespace.

    The Tag: patch-candidate/v3.2.4/mr-101, patch-candidate/v3.2.4/mr-105, 
etc.

    The Extraction: You use a wildcard search to find every tag in that 
"folder."
    Bash

    git tag -l "patch-candidate/v3.2.4/*"

    Pros: Very easy to filter; tags are permanent and searchable.

    Cons: Can clutter your tag list if you have hundreds of MRs (though 
namespaces like patch-candidate/ help).

2. Standardized Commit Trailers (The "Linux Kernel" Way)

Large open-source projects often use "trailers" (key-value pairs at the end of 
a commit message) to track metadata.

    The Workflow: When merging an MR, ensure the merge commit message (or the 
squashed commit) includes a specific string.

        Example: Fixes: #1234. Target-Release: 1.2.1

    The Extraction: You use git log with the --grep flag to find everything 
marked for that release.
    Bash

    git log main --grep="Target-Release: 1.2.1" --format="%H"

    This command returns a list of commit hashes that you can then pipe 
directly into git cherry-pick.

3. The "Integration Branch" Strategy (what "Git" project itself uses)

Instead of labeling individual commits, you use a temporary branch as a 
"bucket" for the next release.

    The Workflow: Every time an MR is merged into main that also needs to go to 
fixes, you immediately cherry-pick it into a "staging" branch called fixes-
pending.

    The Extraction: When it’s time for the actual release, you simply merge 
fixes-pending into fixes.

    Pros: No need to "find" commits later; they are already gathered.

    Cons: Requires immediate action at the time of the original merge, which 
might be a context switch for the developer.


All three are viable, and you could even use it with Gitlab too. But Gitlab is 
not a requirement.

Regards,
  Graeme 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20260417/8ea1a2d3/attachment-0001.sig>