Add RabbitMQ.Client v7 client integration package

[eerhardt]

Description

RabbitMQ.Client shipped a version 7.0.0 that has major breaking changes. Specifically, it removed all sync APIs and only contain async APIs. To continue supporting new versions of RabbitMQ.Client, we need to add a new component Aspire.RabbitMQ.Client.v7 that will work with the new version of RabbitMQ.Client. See #3956 for the strategy to deal with these breaking changes.

Fix #3956

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
• Does the change make any security assumptions or guarantees?
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • No
        • Link to aspire-docs issue (please use this doc-idea template):

Microsoft Reviewers: Open in CodeFlow

[danmoseley]

So from now on, folks that want to use latest will need to pick package named v7, and to use a future v8 rabbitmq they'll need to pick the package named v7 as well. So we have the v7 name indefinitely, if I understand right. Is it worth instead the breaking change to do the reverse, freeze the existing package renaming it v6?

[eerhardt]

So from now on, folks that want to use latest will need to pick package named v7, and to use a future v8 rabbitmq they'll need to pick the package named v7 as well. So we have the v7 name indefinitely, if I understand right. Is it worth instead the breaking change to do the reverse, freeze the existing package renaming it v6?

See #3956 for the strategy to deal with these breaking changes.

[danmoseley]

Yeah I already read that and I was confused so I asked 🙂

When .NET Aspire 9 ships, we can "swap" the dependencies around.
The Aspire.RabbitMQ.Client package will be updated to depend on version 7 of RabbitMQ.Client

I don't think this change did this?
.

If RabbitMQ.Client v6 is still in support, we can create Aspire.RabbitMQ.Client.v6 which has the dependency limit [6.8.1, 7.0.0) and works with the version 6 of RabbitMQ.Client.

We didn't do this either.

What am I missing?

[eerhardt]

When .NET Aspire 9 ships, we can "swap" the dependencies around.
The Aspire.RabbitMQ.Client package will be updated to depend on version 7 of RabbitMQ.Client

I don't think this change did this? .

At the time that issue was written (in April), we were assuming RabbitMQ.Client v7 would ship before .NET Aspire 9. The general strategy is "on the next major version of .NET Aspire". So we will do the "swap" when .NET Aspire 10 ships since RabbitMQ.Client v7 and .NET Aspire 9 shipped at basically the same time.

If RabbitMQ.Client v6 is still in support, we can create Aspire.RabbitMQ.Client.v6 which has the dependency limit [6.8.1, 7.0.0) and works with the version 6 of RabbitMQ.Client.

We didn't do this either.

This would be done at the time of the "swap" (i.e. .NET Aspire 10) if RabbitMQ.Client v6 is still in support and used by customers.

[danmoseley]

Is it worth caching these methodinfos, or is this pattern nearly equivalently fast these days with internal caching? @steveharter