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.orgmailto: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.commailto:David.Wang@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Anton Komlev <Anton.Komlev@arm.commailto:Anton.Komlev@arm.com> Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.commailto:Anton.Komlev@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto: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.orgmailto: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.orgmailto:TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m