Clean version files and update Maestro task version

[jcagme]

Fixes #1949

[dagood]

Poking my nose in... shouldn't this be taking auto-updates from arcade-services, if this library is built there now?

Is the hard-coded version in Versions.props really hard-coded and manually maintained, or am I misunderstanding?

[jcagme]

Yes, when the auto update is done we touch eng/Versions.props, eng/Version.Details.xml and global.json. The version of Microsoft.DotNet.Maestro.Tasks is now defined in src/Microsoft.DotNet.Arcade.Sdk/tools/SdkTasks/Versions.props which is not meant to be auto updated. So there are really two options:

1. Make src/Microsoft.DotNet.Arcade.Sdk/tools/SdkTasks/Versions.props import eng/Version.props and if MicrosoftDotNetMaestroTasksVersion is defined there, use it. This approach will need that all repos add an entry in Version.Details.xml and Versions.props for Microsoft.DotNet.Maestro.Tasks
2. Update the hard coded version manually after there is a change

Given the churn of this library I'll go with 2 for now and it this changes we could look into 1

[chcosta]

We intentionally don't want the sdk tasks projects importing things from elsewhere, particularly from the repo. All of the recent refactoring was to get away from repo weirdness affecting something that's so autonomous. Darc should be taught to update tools/SdkTasks/Versions.props

[dagood]

Oh! I missed that tools/SdkTasks/Versions.props is included as-is in the Arcade SDK. Yeah, that makes things more complicated.

I'd add (3): generate this file during the Arcade build based on the current version in eng/Version.props. This makes the dependency auto-upgrade, but still be static per Arcade SDK build so repos can't introduce mismatch problems by doing unexpected upgrades.

Using (2) for now does seem pragmatic, and I'm fine with that.

[dagood]

Missed @chcosta's comment when posting mine, I agree adding that kind of dependency expression also sounds fine.

[jcagme]

Yup, #1956