Arcade SDK: how do we keep DefaultVersions up-to-date?

[JohnTortugo]

DefaultVersions.props has a static list of the default version of packages used by Arcade SDK. This being a static list means that everytime a bug is fixed in a package used by the SDK we have to create a separate PR to update this list with the patched version of the package.

Can we change this to always use the latest version of the packages by default?

@tmat @alexperovich

[nguerrera]

See #1598 (comment)

[tmat]

I don't think we should. Repos can definitely override the versions if there is a reason for it, but I wouldn't do that unless working around some issue.

The tools listed in DefaultVersions are integrated to Arcade SDK targets. That means a change in the targets might be necessary when the tool changes. For example, let's say we added a new parameter to the sign tool task. Then the targets in Arcade SDK need to pass that parameter. So we can't just automatically consume the new version as soon as it's available.

Also not that not all repositories that use Arcade SDK have dependency uptake.

[nguerrera]

I just don't want repos to be in a situation where we're using some ancient sign tool (or whatever else is default-versioned in arcade) for a long period and then when we need a fix and have to deal with other issues all at once. There should be some process for pushing out newer versions of these tools at some well-defined cadence for repos that are using arcade defaults and arcade uptake.

I think we will get better feedback sooner that way. It is the same thing as for the .NET Core SDK itself that we've discussed. I think ultimately, there needs to be some sort of regular LKG update of all tooling to ensure that we are flighting all tooling changes, in the product or in arcade.

[nguerrera]

CC @markwilkie

[nguerrera]

Also, it is very confusing for arcade consumers that bumping our arcade version to a given version/commit, doesn't give us all of the code in this repo at that commit.

[nguerrera]

The distinction between the arcade SDK and the rest of the arcade packages is too subtle.

[tmat]

Good points. Reopening and renaming the issue. It should definitely not be "by default" for the reasons I stated above but we might want to think about some way how to flow them.

[markwilkie]

Yea - we've discussed this multiple times, but I don't think we've landed at a place of concensus just yet. Let's take it up in the new year when folks are back - I'll take the lead in making that happen.

And yes - I do think we need a mechanism to stay on the latest SDK and packages if desired. Probably using channels via darc is a good place to start. Also, we're in the middle of getting better validation for Arcade and its packages - which is a total prereq to this of course.

cc/ @mmitche

[jcagme]

With the self build approach we are testing the code which was just merged so if there was a bug that CI didn’t catch we’d know right away and the official build would fail. We do this by updating Versions.props.

Then when Maestro PRs are created we do the same and update Versions.props and with that DefaultVersions is not really in play, at least not for the SDK packages

[markwilkie]

I need to move this forward.