Hi,

 

I am wondering if it would be possible to go a bit further and on managing the version number align up with this approach: https://git.trustedfirmware.org/TF-A/cmake-framework.git/tree/doc/versioning_policy.rst?

This would mean to change where and in what format the version number is stored. For TFACMF we decided to add a text file as the main storage format and use the git tag for access purposes only. This may come handy i.e. when tf-m source is “deployed” without git (i.e. cmsis-pack).
Cmake can “generate” the version header based on the content of the text file easy.

As an example this is how TFACMF uses it’s own version: https://git.trustedfirmware.org/TF-A/cmake-framework.git/tree/TFACMFConfigVersion.cmake#n10


/George

 

From: Minos Galanakis <Minos.Galanakis@arm.com>
Sent: 18 November 2020 18:33
To: tf-m@lists.trustedfirmware.org; Gyorgy Szing <Gyorgy.Szing@arm.com>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

Hi,

 

Following up the current discussions on semantic versioning, I have prepared a patch .  Feel free to review and comment.

 

Expanded patch link: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7075/1

 

Minos

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 16 November 2020 17:32
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

Hi,

 

Well, yes. Not sure what backwards compatibility would mean in a complex application with a configurable set of services and service capabilities. Semantic versioning could work quite well for components (i.e. secure service implementations) though.

 

/George

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 16 November 2020 18:04
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

Hi George, All,

 

Thanks for the thoughts. Can I assume that you suggest to stay with option 1?

 

The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it.

 

Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes.

 

Cheers,

Anton

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M
Sent: 16 November 2020 08:17
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

Hi,

 

I miss something here. What is being discussed, what is the purpose of changing version numbering?

  • Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.)
  • Is there need  for expressing backwards compatibility better?
  • Is the aim to enhance existing version numbers just by making them following a well-defined standard?

 

I have the feeling different people are talking about different sub-topics.

 

I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner.

 

/George

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: 16 November 2020 09:06
To: David Hu <David.Hu@arm.com>; David Wang <David.Wang@arm.com>; Anton Komlev <Anton.Komlev@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only.

If TF-M users want all the changes between the release and the fix they can take the master branch as well.

 

Best Regards,

Kevin

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Monday, November 16, 2020 3:45 PM
To: David Wang <David.Wang@arm.com>; tf-m@lists.trustedfirmware.org; Anton Komlev <Anton.Komlev@arm.com>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

Hi Anton,

 

Option 3 seems more reasonable to me.

 

Hi David,

 

I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags.

 

Best regards,

Hu Ziji

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of David Wang via TF-M
Sent: Monday, November 16, 2020 2:53 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Semantic versioning

 

Hi Anton,

Option 3 is a good.

Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we:

  • Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or
  • Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1

 

Thanks.

 

Regards,

David Wang

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: Saturday, November 14, 2020 3:45 AM
To: Anton Komlev <Anton.Komlev@arm.com>
Cc: nd <nd@arm.com>; tf-m@lists.trustedfirmware.org
Subject: Re: [TF-M] Semantic versioning

 

Hi Anton,

 

Option 3 seems the most sensible to me for a project like TF-M at this stage.

 

Best regards,

Kevin

 

On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m@lists.trustedfirmware.org> wrote:

Hi,

 

I would like to continue the discussion on TF-M semantic versioning started on the last tech forum.

Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A.

There are several calls to switch TF-M to semantic versioning.

Here is the reminder of the meaning: (https://semver.org/) v1.2.3 :

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.

 

This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed:

  1. Do nothing, reasonably bumping up versions on release time only.
  2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between.
  3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version.
  4. Other ideas?

 

Personally I tend to follow option 3 but looking for the community input.

 

Thanks,

Anton.

--
TF-M mailing list
TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m