How do we use tags on master branch?

[dbaluta]

This questions starts from sof-logger output:

ERROR FW ABI 0x3012001 DBG ABI 0x5002001 tag v1.5-rc1-996-g69073c6ae4db src hash 0xc4ec3834 (ldc hash 0xc4ec3834)
This output looks to be correct because:

GIT_TAG = git describe --tags --abbrev=12 --match v*
and
$ git describe --tags --abbrev=12 --match v v1.5-rc1-996-g69073c6ae4db
So, the question is how do we actually use tags? And what's their relation with our releases.

Cc: @xiulipan @marc-hb @paulstelian97 @TE-N-ShengjiuWang
@lgirdwood @plbossart

[paulstelian97]

I think a tag is made for every RC and release, and when doing git describe the most recent tag that points to a commit on the branch is selected. Not sure what happens if two tags point to the same commit though, but I mean I think we shouldn't get into that case anyway.

[dbaluta]

@paulstelian97 OK, it could be an explanation. But I have more questions:

• it means that TAG for master doesn't have a meaning?
• and why do we need both tag and src hash?

[lgirdwood]

I would expect we would have the same rules as Linux here, but it looks like we are always adding the commit ID (even when commit is a tag) ?

[paulstelian97]

I think src hash is used to identify a specific commit after the tag (tags do NOT move with new commits like branches do).

Tags point to fixed, specific commits. Tags for master are generally releases or RCs at least for this project.

In Git, tags and branches are almost the same, except branches evolve as new commits are added while tags stay attached to a specific commit. Checking out a tag always puts you in "detached HEAD" in fact.

[dbaluta]

@paulstelian97 @lgirdwood First thing we need to figure out why do we need the tag information in logs. I suspect that this is an easy way for the reader to identify release version.

[lgirdwood]

@ktrzcinx @abonislawski @slawblauciak any idea why the tag info is in logs ?

[marc-hb]

I see (at least) three distinct questions:

1. Why would anyone not want git version information in logs that get attached to test runs and bug reports?
2. Fine-tuning of git describe parameters. The current git describe parameters look OK to me, please be specific about how you would like to change them and why.
3. The source hash is unrelated to the git version. The source hash makes sure the dictionary is compatible with the logger, see longer discussion in Logger abi check #3195

[xiulipan]

@ktrzcinx @abonislawski @slawblauciak any idea why the tag info is in logs ?

First answer why we have tag info, this is a part of our sof_ipc_fw_ready structure to dmesg log and work as HELLO WORLD TRACE log for trace system.(also see my email about 1.7 release yesterday)

dmesg
[    5.228533] kernel: sof-audio-pci 0000:00:1f.3: Firmware info: version 1:5:0-3c201
trace HELLO WORLD message
ERROR FW ABI 0x3012001 DBG ABI 0x5002001 tag v1.5-rc1-999-g3c20133263d5 src hash 0x2cfdece9 (ldc hash 0x2cfdece9)

@lgirdwood @dbaluta @paulstelian97 I see similar issue in our release process. We are making VERSION TAG from git tag.
which means if a git tag is not on master branch, the git description will try to use the latest tag on the branch.

 git describe --tags --abbrev=12 --match v*
v1.5-rc1-999-g3c20133263d5

So take above output as example
v1.5-rc1 - the latest tag with regex v*
999 - the master head now has 996 commits
g3c20133263d5 - the head git commit is 3c20133

git log v1.5-rc1..HEAD --oneline |wc
    999    8044   62576

Even thought we are in release v1.6.1, the TAG v1.6.1 is on the release branch and not on master branch.

To solve the issue we have 2 ways:

• always tag on master branch
• use static version info.

[marc-hb]

Even thought we are in release v1.6.1, the TAG v1.6.1 is on the release branch and not on master branch.

The master branch should not try to look like the v1.6.x branch because it's not, it has different code.

The reason the master branch looks like v1.5-rc1+something is because it is v1.5-rc1 plus something.

A typical process is to tag the first Release Candidate on the master branch, that's apparently what was done for v1.5-rc1. I don't know why it wasn't done for v1.6-rc1, see below.

*     2b54bacdb289 naveen.m@intel.com // topology: add KWD component into sof-tgl-sdw-max98373-rt5682
*     4c78e94a08eb yong.zhi@intel.com // topology: fix playback & capture pipelines to be timer driven
*     7bda1c831541 ranjani.sridharan@linux.intel.com // config: cht: remove tone comp
*     5abdf3778be8 ranjani.sridharan@linux.intel.com // volume: fix get_cmd() for SWITCH command
*     cad15f040501 karolx.trzcinski@linux.intel.com // rimage: Use only standard error codes
*     20fbbe77e474 yang.jie@linux.intel.com // topology: pipe-amp-ref-capture: correct the setting of ref channels
*     739554defaea yang.jie@linux.intel.com // topology: sof-tgl-nocodec-ci: remove KWD pipelines as not available
*     0a247928bb3f marc.herbert@intel.com // travis: upgrade distribution to Ubuntu 20.04
*     aa20048e92dc marc.herbert@intel.com // travis: fold long lines; fixes the last yamllint warnings
| *     7dd4c41d2e08 seppo.ingalsuo@linux.intel.com // (tag: v1.6-rc1) Audio: Continue volume ramp until all chann>
| *     478eb6874370 yong.zhi@intel.com // topology: fix playback & capture pipelines to be timer driven
| *     f3435914de2c ranjani.sridharan@linux.intel.com // config: cht: remove tone comp
| *     8af2c1da7c24 ranjani.sridharan@linux.intel.com // volume: fix get_cmd() for SWITCH command
| *     dc3015aa3e83 karolx.trzcinski@linux.intel.com // rimage: Use only standard error codes
| *     20fc71fad3ef yang.jie@linux.intel.com // topology: pipe-amp-ref-capture: correct the setting of ref channe>
| *     ab8a3564d750 yang.jie@linux.intel.com // topology: sof-tgl-nocodec-ci: remove KWD pipelines as not availab>
| *     2e259f45fe5a marc.herbert@intel.com // travis: upgrade distribution to Ubuntu 20.04
| *     61b521889ac2 marc.herbert@intel.com // travis: fold long lines; fixes the last yamllint warnings
|/  
*     6e98d9dde423 marc.herbert@intel.com // CODEOWNERS: really add marc-hb to scripts
*     c40749b9817f marc.herbert@intel.com // CODEOWNERS: fix path to dmic.
*     0e1176d9434a karolx.trzcinski@linux.intel.com // trace: Update trace level after ipc message
*     82c005c713d9 karolx.trzcinski@linux.intel.com // ipc: trace: Add trace filter message handling
*     7b5365f776c7 marcin.rajwa@linux.intel.com // dai: add warning when we skip .copy
*     dd5a56f37b91 karolx.trzcinski@linux.intel.com // rimage: Update to version with toml devices description
*     88b69cc2e5ca ranjani.sridharan@linux.intel.com // scripts: xtensa-build-all: Add support for building TGL an>
*     dfd2336bb2e7 marc.herbert@intel.com // cmake: empty MEU_OPENSSL param is now the same as not defined

[marc-hb]

I suggest the following "fix":

$ git tag v1.6-rc0 6e98d9dde423
$ git describe --match 'v*' --tags 3c20133263d5
v1.6-rc0-285-g3c20133263d5

Please thumbs up or down this github comment.

[dbaluta]

@marc-hb this means that we will need to manually update the current rc0 version each time we release a new version, right?

[marc-hb]

I'm not sure what you mean by "update the current rc0 version".

Ideally, every vN.M-rc1 release candidate (and only the first -rc1 release candidate) would be on the master branch. If that's not possible for some reason, then my suggestion above is to have a "dummy" vN.M-rc0 tag or vN.M-branchpoint tag on the master branch with no actual release candidate matching it.

[dbaluta]

@marc-hb OK, I understand your point now. Having vN.M-rc1 on master branch looks like an acceptable solution.

[lgirdwood]

@marc-hb I assuming you are proposing the same version schema that Linux uses here ? If so I approve.

[marc-hb]

Not sure what you mean by "version schema", I don't think I've been proposing any schema. I only proposed to tag the master branch near each release branch point which I think answered the main question.