What do non-public/partner releases look like for .NET 8?

[omajid]

For .NET 6 and .NET 7, Microsoft makes a few things available to partners ahead of a public .NET release:

• A source code repository with the release tagged
• A source archive (.tar.gz file ) for .NET

With the .NET 8 model (VMR), the VMR public release looks like this:

• A source code repository (dotnet/dotnet) with the release tagged
• A source code archive (.tar.gz) auto-generated by github
• A release.json file

Does the non-public/partner release look the same? If not, what pieces are going to be available and how can we generate the rest?

For example, if there's a source code repository with the release tagged, I can generate a tar.gz using git archive. What can I do to make sure it matches the tarball that's available from GitHub when the release is public?

What about release.json? Will that be published? Will there be a way to generate something that works for everyone post-public-GA (that is, refer to the same commits on the public github repos)?

How does the ability to verify releases (see #3316) work for these partner releases?

[mmitche]

For example, if there's a source code repository with the release tagged, I can generate a tar.gz using git archive. What can I do to make sure it matches the tarball that's available from GitHub when the release is public?

@omajid I struggled with this a bit around verifying the GitHub tarballs. I was unable to reliably generate a local git archive from our repos that exactly matches the GitHub tarball. The checksums of the tarballs always varied. From what I can tell, this probably has to do with the gzip and git versions that are in use on local machine vs. GitHub servers. I was, however, able to unpack the tarballs and do directory comparisons on them (diff -qr) and get zero diff. I would recommend this approach

Because the GitHub release and associated tarballs are only available when we make the tags public, we can only provide the signatures of the tarballs at that point. Prior to release day, we'll have a tag in the internal partner repo which you can generate the archive off of. Unfortunately, there's no analogous release mechanism in AzDO that allows for a GitHub style workflow prior to release day.

[mmitche]

@omajid We had a discussion about this in today's SB sync. Here is a proposal, and let me know what you think:

• For 8.0, we would add back the tarball to the pre-release day artifacts that partners have access to. This would just be a git archive generated from the partners repo.
• We would add a detached signature for the internal partner tarball
• We would add a release.json alongside.
• On release day, you could verify the tarball you built against the public github release source tarball by doing a recursive directory compare of the two tarballs. We would still maintain the new signatures of the public tarball.

Note that the public detached signature and the internal detached signature would not match. Or, at least, they would be not guaranteed to match.

[MichaelSimons]

[Triage] @oleksandr-didyk, can you consider this a higher priority release infra improvement over others? Ideally this would be available in the Dec timeframe if not then, January.

[omajid]

@mmitche This sounds sensible to me, given our constraints. Thank you!

Would it be possible to produce a detached signature file on the partner side too? Then we (or anyone worried about authenticity of the source) could verify the parter-tarball using the partner-signature and the public-tarball using the public-signature.

[mmitche]

@mmitche This sounds sensible to me, given our constraints. Thank you!

Would it be possible to produce a detached signature file on the partner side too? Then we (or anyone worried about authenticity of the source) could verify the parter-tarball using the partner-signature and the public-tarball using the public-signature.

Yes, we can do that.

[mmitche]

I updated my list above to include the partner signature