Increase Extensibility in TagGenerator.py

[makubacki]

Background

Scripts/TagGenerator/TagGenerator.py contains code to automatically tag a commit with a release version tag for ADO use cases where GitHub Actions don't apply.

The script currently specifies a single semantic versioning format that works for Mu repos:

• <Major>.<Minor>.<Patch>

Other consumers have expressed interest in the script but need to use a custom version format. In this particular case:

• [ProductName].[VendorNumber].[FirmwareComponent].[MajorVersion][MinorVersion].[Sku].[Patch]

An original Project Mu versioning goal was to drive consistent versioning through a well-established standard like semantic versioning. Given a deviation is needed due to conflicting requirements for this consumer, the issue proposes changes to handle both formats.

It is still a goal in this proposal to make the versioning information completely visible in mu_devops without depending on ambiguous gaps filled in by code elsewhere. This keeps opinionated consistency in place, makes the code here more useful to a broader set of users, and makes overall maintenance of the code much easier in a single upstream location.

Details

I'd prefer to continue to capture the full context of the version in a mu_devops script. Ideally, different formats would be abstracted behind a class. The class would provide information needed to make common decisions irrespective of the underlying format details. Then we don't need half-baked information here connected with other scripts elsewhere, all of the version information can be maintained behind a single abstracted version API. This also gives the benefit that other Python code using the class wouldn't need to change significantly if the underlying version format changed in the future.

Module level functions like is_breaking_change(), is_security_change(), is_new_feature(), generate_notes(), etc. would become class methods and return consistent information regardless of how they return the format for the underlying version.

In the end, this would mean:

• That the existing format ("semantic versioning format") and new format ("Product Component format") would have their underlying format details readily visible to developers that look at the scripts in mu_devops.
  • Other projects can easily choose the appropriate format without reinventing the wheel.
• Other Python code can use the class API to get various version information regardless of the underlying format details.
• The script can easily and obviously be extended in the future to support new formats without modifying various lines of code here and there in the procedural logic which is error prone and messy.
• Mu Devops still provides ready-to-use versioning schemes that don't need details filled in elsewhere.

---

This issue is in reference to tracking a change discussed in #293.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in 45 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically been closed because it did not have any activity in 45 days and no follow up within 7 days after being marked stale. Thank you for your contributions.