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 :
- MAJOR version when you make incompatible API changes,
- 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:
- Do nothing, reasonably bumping up versions on release time only.
- 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