Any hint for CMSIS Packs release flow ?

[LMESTM]

When a PACK release candidate is created by a development team:
-> the PACK version is created : 1.0.0-rc2, the PACK will be named accordingly : ST.mypack.1.0.0-rc2.pack

The PACK will need to go through the validation flow.

• If any tests are failed, it needs to go back to development team which needs to produce an rc3 candidate
• If all tests are ok, we're good to publish 1.0.0 version

Is there any recommendation for naming the field inside the PDSC during the flow ?

• Do we need to have the same version in and in .pack name ?
• or is it acceptable to use the final version (e.g. 1.0.0) in release field, while the .pack goes through different names during the process ( ST.mypack.1.0.0-rc1.pack, ST.mypack.1.0.0-rc2.pack, ST.mypack.1.0.0.pack ....)

[jkrech]

The rule is that both the pack filename <version> part needs to exactly match the version attribute specified as the latest version <release> tag at the top of the <releases> section. Once the final release is done you can consolidate the release notes from the different release candidates into the final public release and remove the rc* entries as they won't be available for public download.

[JonatanAntoni]

Hi all,

Having files with (static) version information committed to the repo is always a source for trouble.
Hence, I tried to come up with a workflow that inferes the version from Git history on-the-fly when generating the pack.

Please review what I did in the following repos:

• https://github.com/ARM-software/CMSIS-DSP
• https://github.com/ARM-software/Arm-2D

The approach is as follows:

• Each (release) version is marked using an "annotated tag" in the Git history. An annotated tag has a message associated. The message is used to carry the release notes that shall show up in the changelog.
• The pack version is inferred from the tag name by using git describe. This can either be the tags name if the version used for building is tagged. Or the version of the latest tag is used, incremented and suffixed with an additional qualifier to mark it a dev drop.
• The content of the pdsc file is updated on-the-fly during pack generation by iterating all annotated tags.

Please let me know if this looks viable to you.

Thanks,
Jonatan

[LMESTM]

HI @JonatanAntoni thanks for sharing your inputs. I will try to have a look (maybe after summer break)
One extra question for now: do you think your proposal can manage the cases mentioned above:

• create a tag for release candidate before validation steps
• create another tag for final release, pointing to the same commit => the resulting release history in pdsc should only refer to the release, not the candidates

I guess this point might be managed in the generation script of course, just wondering if you're following the same steps.

[JonatanAntoni]

Hi @LMESTM,

The current version of the script would probably not handle your cases correctly. But I am quite confident that the script can be enhanced to do it. The most interesting point might be the behaviour of git describe when it has multiple tags at a single commit.

And we need to discuss how to filter tags from the history when generating the changelog. Currently, I just use all tags with a specific prefix. Having pre-release tags in between these would also show up in the (final) release history.

Cheers,
Jonatan

[LMESTM]

thanks @JonatanAntoni - I think the proposal looks interesting and could cope with my use case. I will try it out and discuss with colleagues to see if we should go in that direction

Are the CMSIS-DSP and Arm-2D packs available for download if I want to easily compare the generated release content in pdsc with the git
commits and tags history .

[LMESTM]

Hi @JonatanAntoni @jkrech
The issue we see with the proposal is that a new PACK needs to be created after VX.Y-RCn is considered the valid version. So the PACK will actually be a new pack with a different pdsc version.
The below idea was discussed within ST

• Developers create a tag release candidate (v1.0.0-rc1), create a pack with this content. The content of this pack rc1 must reflect exactly the expected v1.0.0 including release note, pdsc, #define with version v1.0.0 here. (it would not reference rc1 anywhere!)
• In case of rejection due to a failed test, a new pack is created with rc+1.
• When the final check is ok, the pack is only RENAMED to v1.0.0 (no content update) and uploaded to prod server. (No other checks required, same checksum)

That would mean we're back to your previous question

Assuming that you are using the final pack version in the pdsc but a different version for the pack filename, what are your expectations regarding the tools? Do you expect the pack installer to use the pack's version to determine the installation directory? Do you expect csolution to take the filename of the pack somehow into consideration?

That proposal would probably require specific handling of all -rcX packs so that only pdsc refers to 1.2.3 and tools should use the latest version between 12.3 and 1.2.3-rcX. Possibly this indeeed requires to use the .pack name to define the directory - isn't that the case today ? It should also allow installation of newer versions to replace rcN by rcN+1 and the final release in the end

feedbacks welcome

[jkrech]

@LMESTM the CMSIS-DSP pack is attached as asset to the releases in the repo. The latest is:
https://github.com/ARM-software/CMSIS-DSP/releases/download/v1.11.0/ARM.CMSIS-DSP.1.11.0.pack

For Arm-2D the latest is here:
https://github.com/ARM-software/Arm-2D/releases/download/v1.0.0-preview4/ARM.Arm-2D.1.0.0-preview4.pack

[LMESTM]

thanks @jkrech

[jkrech]

Regarding the directory name being derived from filename <vendor>.<name>.<version>.pack or the tags from the pdsc file, we did not have to specify anything so far, because we always required both to be the same.
However any tool reading the pdsc files of the installed packs would complain about duplicate packs, since these tools are required to read the pdsc file and take the version from the XML tags rather than the directory name. This would mean you must not have multiple "RC versions" of a pack installed.
Maybe you just try it and let us know your findings...

[LMESTM]

I would indeed expect only the latest version to be installed, not multiple ones ... that would require the pack installer to replace rc1 folder, by rc2 folder ... then ultimately by the final version. This also somehow requires maintenance of index files accordingly (only keep latest version ... ). I think we'll need to give it a try indeed !