Hi,

Yes, I agree it can be confusing as any static version reference becomes outdated with the first post-release change.

Just to recap, 3 use cases for handling TF-M versioning:

1. A Git repository with tags
2. A Git repository without tags
3. Plain source code with no Git

In cases 2 and 3, the TFM_VERSION_MANUAL variable is used to define the version manually.

To clearly distinguish ongoing development in the main from the last release, we could use a notation like “2.2.1+”, indicating it's an increment beyond the 2.2.1 release.

Does that approach make sense?

Best regards,
Anton

From: Chris.Brand--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, November 25, 2025 10:15 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] TFM_VERSION

I notice that TFM_VERSION_MANUAL gets set to “2.2.1” in both release/2.2.x and in main. Granted, the hash gets appended to make TFM_VERSION, and there’s some reading of git tags involved that can override TFM_VERSION_MANUAL, but it still feels odd that both identify as the “same” version.

Perhaps main should be flagged as being the “next” version as soon as the previous version branch has been created? So we would tag main as v2.3.pre or something. Either that or something that identifies as *not* being a regular release.

Chris