TSMP release candidate(s)

[DCaviedesV]

We are converging into a new tagged release. When looking at the tagged releases we have the most recent 1.2.3 and slightly older 1.3.3. This is of course confusing, and we need to determine the correct tag version number for this release.

It is also relevant to consider if there are other issues to solve in such immediate release candidate @s-poll, @niklaswr.
My proposal would be to have the next release including the current Master, msa_build_interface and solving Stages/2023 readiness.
@jjokella, do you think we can already include here TSMP-PDAF? (If so, should this then be v1.4.0 ?)

After that, the following release candidate should address #147, #167 and #144.

[niklaswr]

Going for a new tagged release sounds good, as well as tackling the version numbering.
Is the versioning scheme documented anywhere? Sounds like semantic versioning, but I am not sure how strictly this has been applied in the past.

I would add #173 as a release candidate with the ordered priority:
#147
#173 #144 #167

[DCaviedesV]

Yes, it is meant to be semantic versioning, but has been a bit misused in the past.
We have now agreed that the release candidate will be 1.4.0.

[jjokella]

@jjokella, do you think we can already include here TSMP-PDAF? (If so, should this then be v1.4.0 ?)

I am not sure how long the TSMP-PDAF PR will take. I will work on making its changes to files outside of intf_DA more transparent, such that all major developers can easily review it.

It depends also on how long the other developments will take.

[jjokella]

Update: I have now re-checked the TSMP-PDAF PR(s) and from my side, the release_candidate-PR is good to go. The master-PR could be closed or merged as well.