search

dotnet / extensions

This repository contains a suite of libraries that provide facilities commonly needed when creating production-ready applications.
MIT License
2.63k stars 751 forks source link

Missing assemblies in the Microsoft.Internal.Extensions.DotNetApiDocs.Transport package #4572

Closed carlossanlop closed 11 months ago

carlossanlop commented 1 year ago

The Microsoft.Internal.Extensions.DotNetApiDocs.Transport package is missing some assemblies that we were expecting to see included (from a list provided by @joperezr):

Also, should we expect these two to be included as well? Asking because they were not included in @joperezr 's list:

cc @gewarren

joperezr commented 1 year ago

Yes, all of the above should be part of the transport package. @carlossanlop I'm assuming you are looking into this? If so, can I assign you?

carlossanlop commented 1 year ago

We expect the extensions folks to take ownership from this point on, so I opened the two issues for the remaining work.

gewarren commented 1 year ago

@joperezr None of these are on NuGet. Is that expected?

Microsoft.Extensions.Diagnostics.Extra Microsoft.Extensions.Diagnostics.ExtraAbstractions Microsoft.Extensions.Diagnostics.Testing Microsoft.Extensions.Http.Diagnostics

joperezr commented 1 year ago

Yes, that is expected. I do want to apologize to you and @carlossanlop for all of the back and forth here as it is mainly our fault. The main issue is as follows: most dotnet repos are usually pretty stable in terms of assemblies that get published, as well as APIs inside those assemblies. This is specially the case this close to the release.

dotnet/extensions on the other hand, has been a bit different. We mainly focused on features during the early previews, without focusing too much on API shapes or assembly names. Now, during RC1, RC2 and GA branches, we have been focusing on those things, which has resulted in some API small changes and adjustments, as well as some assembly renames, which explain why the package names have changed from Rc1, Rc2, and currently set to ship for GA. It is also worth noting that we are not done with these changes, and some are still expected to change a bit in this next week. This means that the source of truth for what the set of assemblies are, is to basically look at what's inside the transport package (assuming it is correctly collecting all of the assemblies we produce from the build).

Again, I understand that this is a special case and that it is not ideal for the documentation work you do, so I do apologize for the trouble. What do you think is the best way forward and to get you what you need?

gewarren commented 1 year ago

This means that the source of truth for what the set of assemblies are, is to basically look at what's inside the transport package (assuming it is correctly collecting all of the assemblies we produce from the build).

That should be all I need for docs. Thanks!

RussKie commented 11 months ago

Microsoft.Internal.Extensions.DotNetApiDocs.Transport represents the current state (i.e., contains the shippable packages) for each release.