coreclr-tools (ILAsm/ILDasm) should be released every version similar to targeting packs

[crummel]

In order to make source-build simpler, the runtime started shipping targeting packs every patch release even when there were no changes, so that, for example, the 6.0.1 targeting pack was released even when it was identical to 6.0.0 except for the version number. We now see a similar issue with ILAsm and ILDasm in 7.0 servicing - there was no 7.0.1 version of these released and source-build has no way to reliably know what the "last known good" version is. Is it possible to release these tools the same way so source-build can use the most current version number without having to maintain LKG version numbers?

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In order to make source-build simpler, the runtime started shipping targeting packs even patch release even when there were no changes, so that, for example, the 6.0.1 targeting pack was released even when it was identical to 6.0.0 except for the version number. We now see a similar issue with ILAsm and ILDasm in 7.0 servicing - there was no 7.0.1 version of these released and source-build has no way to reliably know what the "last known good" version is. Is it possible to release these tools the same way so source-build can use the most current version number without having to maintain LKG version numbers?

Author:	crummel
Assignees:	-
Labels:	area-ILTools-coreclr, source-build, untriaged
Milestone:	-

[mmitche]

@crummel There are a number of packages that runtime incrementally services. What makes ILAsm/ILDasm different than them? Is it that the IL* tools are foundational inputs to the runtime build and so we need to know what version to use from the previously source-built artifacts?

@JulieLeeMSFT I believe the ask would be evaluate any downsides of shipping these packages every month. If we decided to do so, then we'd switch to simply producing the ILAsm/ILDasm packages on every runtime servicing cycle, rather than selectively. I do not know how this is done for these packages.

/cc @carlossanlop.

[crummel]

Yes, this causes problems when bootstrapping - since source-build assumes that the version available in previously-source-built is also publicly available, when we try to bootstrap e.g. version 7.0.103 we look for ILAsm 7.0.102 which doesn't exist. The problem with having source-build only produce the 7.0.0 is that then servicing is no longer an N-1 issue for maintainers - it's an N-1 and N-3 and N-7 (or wherever the necessary packages are) issue. We've talked about carrying these types of packages forward into the next previously-source-built but that makes poisoning harder to enforce and likely would not be considered source-build-clean by distros.