On Fri, 5 Nov 2021 at 16:24, Jasper Orschulko <
Jasper.Orschulko@iris-sensing.com> wrote:

In our case some binary which is made up from some 50ish separately
versioned sub-components. We used to have separate recipes for each of
this components and static link them using DEPENDS. However, this does
not scale well. E.g. if you want to create another version with
different cmake flags, you would have to create copies of all 50ish
recipes. You could move all the components into a single recipe and do
50x git fetcher, but keeping this versioned is still painful.
Especially since the developers mainly don't use yocto but use the SDK
for cross-compiling. As such this used to mean, that versioning in the
development workflow and the release workflow worked differently ->
more maintenance work.

With repo fetcher we can streamline the versioning within the yocto
build process and the daily developer workflow, as both can fetch the
repo manifest from a central stored git repo. The idea is, that the
repo manifest defaults to develop branch for all component repos and if
we want to create a release we can use repos own tooling to
automatically create fixed refspecs from the development manifest.
something like `repo manifest -r -o release-1.0.0.xml`, push that as a
release to the manifest repo, set this release as refspec in the recipe
within the meta layer and proceed with the release process. So no more
manually maintaining the component versioning within the yocto recipes.

I see. I don't particularly endorse that you invented a custom, proprietary
workflow that you have to support entirely by yourselves - instead of
finding ways to do what you need with standard yocto tooling, improving the
tooling where/if necessary. But if that works out ok for you, then fine :)

Alex