Decide how to handle Scarthgap meta-lts-mixins dependency

[MaxIhlenfeldt]

meta-lts-mixins now has a scarthgap/rust branch: https://git.yoctoproject.org/meta-lts-mixins/log/?h=scarthgap/rust.

To avoid re-introducing #789 for Scarthgap, I think we should declare a dependency on meta-lts-mixins (as soon as we drop the patch to keep the required Rust version at 1.75) - but of course we don't have that dependency for Styhead or Walnascar.

One way to solve this problem would be to stop using the master branch for all currently supported releases, and instead have one branch per Yocto release (which we currently only do once we stop supporting a release). In my experience we've always been in the minority with our current approach - and switching to one branch per release by default would have other advantages as well, e.g. not blocking the update for other releases if the build is only broken for one release.

@rakuco @kraj @otavio wdyt? If we switch our branch approach, how can we best handle it to break as few user's setups as possible?

[rakuco]

In the past, the cost of maintaining multiple branches at the same time to track multiple OE releases seemed to high compared to just making master work with as many branches as possible. Is your suggestion to land a milestone update to master and then create N pull requests cherry-picking the change to other branches?

While not future-proof, I wonder if we could just detect the Rust version in one of the tasks and point users to the branch if necessary (like we do for LLVM).

[MaxIhlenfeldt]

Is the maintenance cost of multiple branches so high? It seems not too high to me, especially when weighed against the advantages as outlined above.

Is your suggestion to land a milestone update to master and then create N pull requests cherry-picking the change to other branches?

Yes, exactly.

I wonder if we could just detect the Rust version in one of the tasks and point users to the branch if necessary

We could do that, but personally I think separate branches would be cleaner. But you've been a maintainer longer than me, so I might be underestimating the effort or overestimating the advantages 😄

[otavio]

One possibility that we could try to follow would be to support just the master and the LTS branches. Using this approach, we would reduce the number of branches we need to maintain, while also providing a more stable and immutable set of branches for users to rely on.

[rakuco]

We could do that, but personally I think separate branches would be cleaner. But you've been a maintainer longer than me, so I might be underestimating the effort or overestimating the advantages 😄

You've been doing a lot more work in the past few years so I'd trust your input more than mine here :-)

Working on a single branch feels the easiest to me, but I'm fine following the "those who code decide" option here. Otavio's suggestion is complimentary: we could both choose to support a smaller number of branches and create separate branches for each supported release.

[MaxIhlenfeldt]

Otavio's suggestion is complimentary: we could both choose to support a smaller number of branches and create separate branches for each supported release.

I think that's a sensible middle ground. I'll create a scarthgap branch later this week and will also update the readme to include our support policy.