Host Split Update host build pipeline to publish a new FunctionsInproc site extension

[aishwaryabh]

Issue describing the changes in this PR

resolves #9722

On a high level, the pipeline pushes the dev branch to release/4.x and release/inproc6/4.x. The first branch will generate an artifact called Functions.4.1030.zip and the second branch will generate an artifact called FunctionsInProc.4.630.zip.

We are calling in-proc 4.6xx and OOP 4.10xx to specify the host .NET version without having to make another query. So 4.6xx means we're using .NET 6. We chose to add 10 to the minor prefix of the version since we want the version for isolated to be larger than the version for in-proc.

The following site extension is built when testing with aishwarya/release/inproc6/4.99:

And the following site extension is built when testing with aishwarya/release/4.99:

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

Additional information

Additional PR information

[jviau]

Can you elaborate on why we chose in-proc to have 4.6xx versions and out of proc 4.10xx?

[aishwaryabh]

Can you elaborate on why we chose in-proc to have 4.6xx versions and out of proc 4.10xx?

I added an additional description to the PR:

We are calling in-proc 4.6xx and OOP 4.10xx to specify the host .NET version without having to make another query. So 4.6xx means we're using .NET 6. We chose to add 10 to the minor prefix of the version since we want the version for isolated to be larger than the version for in-proc.

[jviau]

Okay. Now I am wondering why 10 and not 8 😆 , as it is .net8

[brettsam]

@jviau -- there will be a 4.8xx coming soon -- specifically for .NET 8 in-proc support (we'll have 3 flavors of v4 for some time...).

We chose 10xx just to get higher than that so we would avoid any future conflict. We don't expect many .NET 8 in-proc releases -- and certainly not 200 of them to catch up, but 10xx just seemed nice and round.

And while the new out-of-proc is going to be .NET 8... it'll also move to .NET 9, 10, 11, etc, so the prefix wasn't super-critical for matching that version. It's going to be long-lived so we just wanted that prefix to be high enough to be "out of the way".