Update recipes-azure to lts 07 2020

[saulwold]

This set of commits updates the SRCREVs of the recipes to the HEAD of lts_07_2020 branches where appropriate, when the branch does not exist, the update goes as far as is compatible with repos that do not have lts_07_2020 branches.

Sau!

[srware]

Hi @saulwold ,

Looking into the versioning again I might backtrack on my initial views. Moving to the lts branch makes sense from a maintenance perspective but also means we could just pick up head rather then specifying a revision fetch. However, to do this the PV needs to auto increment.

My proposal would be to change the recipe name to include the branch (e.g. azure-c-shared-utility_lts-07-2020) and then append the SRCPV in the recipe: PV_append = "+git${SRCPV}" It's probably bad practice not to specify a commit for reproducibility so I am also happy to leave this in but I think for lts branches where the semantic version may get forgotten moving to a different PV approach makes sense.

Thoughts?

[saulwold]

Hi @saulwold ,

Looking into the versioning again I might backtrack on my initial views. Moving to the lts branch makes sense from a maintenance perspective but also means we could just pick up head rather then specifying a revision fetch. However, to do this the PV needs to auto increment.

My proposal would be to change the recipe name to include the branch (e.g. azure-c-shared-utility_lts-07-2020) and then append the SRCPV in the recipe: PV_append = "+git${SRCPV}" It's probably bad practice not to specify a commit for reproducibility so I am also happy to leave this in but I think for lts branches where the semantic version may get forgotten moving to a different PV approach makes sense.

Thoughts?

I think the more correct naming is _git.bb with PV = "lts-07-2020+git${SRCPV}"

We could even go as far as setting BRANCH="lts-07-2020" and use ${BRANCH} in the SRC_URI and the PV

PV= "${BRANCH}+git${SRCPV}"

Sau!

[srware]

Hi @saulwold ,

The _git naming convention in my experience is used when a recipe is simply picking up mainline HEAD. As we are defining a release branch I think it would be less confusing for the end-user if we versioned the recipe as such so it's clear which version this recipe is building.

I'm happy with your proposal for setting PV in the recipe though. This will make the recipe portable as we move to newer LTS branches in the future.

Thanks.

[saulwold]

Hi @saulwold ,

The _git naming convention in my experience is used when a recipe is simply picking up mainline HEAD. As we are defining a release branch I think it would be less confusing for the end-user if we versioned the recipe as such so it's clear which version this recipe is building.

Hmm, our experience varies then, the _git is for git based projects and all of oe-core, meta-openembedded and meta-virtualization, even meta-intal use _git and a fixed SRCREV (not AUTOREV). They all set PV similar to what I have proposed. So I think we should use the _git naming as that is the common convention for the majority of OpenEmbedded layers.

I'm happy with your proposal for setting PV in the recipe though. This will make the recipe portable as we move to newer LTS branches in the future.

Yes, it will work nicely for that.

Sau!

Thanks.

[srware]

OK, it's a small detail so happy to use just _git. As long as the branch is clearly visible in the recipe.

Thanks.

[saulwold]

Closing in favor of a newer one with renamed recipes