Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Component docs #4270

Merged
merged 4 commits into from
May 29, 2024
Merged

Update Component docs #4270

merged 4 commits into from
May 29, 2024

Conversation

eerhardt
Copy link
Member

@eerhardt eerhardt commented May 23, 2024

  • Add information on versioning and breaking changes from dependencies
  • Add EndToEnd test information to the checklist
Microsoft Reviewers: Open in CodeFlow

- Add information on versioning and breaking changes from dependencies
- Add EndToEnd test information to the checklist
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-integrations Issues pertaining to Aspire Integrations packages label May 23, 2024
src/Components/README.md Outdated Show resolved Hide resolved
Copy link
Member

@joperezr joperezr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny comment, but looks great otherwise. Thanks Eric

To understand how this will work, an example of this is the `RabbitMQ.Client` library made many large breaking changes between version `6.8.1` and `7.0.0`. To handle this:

1. For the current `Aspire.RabbitMQ.Client` package, we put a NuGet version limit on our dependency: `[6.8.1,7.0.0)`. This way people won't be able to update to the `7.0.0` version, which will break their app.
2. When `RabbitMQ.Client` ships an official `7.0.0` stable package during the .NET Aspire `8.x` lifetime, we can add a new, forked component named `Aspire.RabbitMQ.Client.v7` which will have a dependency on `7.0.0` and contain any updates so the .NET Aspire component will work with v7. People who explicitly want to use v7 can opt into using this package.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny detail, but before there is a stable version, should we still create a version constraint? I'd probably suggest not to put a constraint until we have a package for the new version, since if we do it before, there will be an interim were an app that really needs to use the new preview version won't be able to with Aspire.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

before there is a stable version, should we still create a version constraint?

In my opinion, yes. This is the situation we are currently in with RabbitMQ. They currently have 7.0.0-alpha.6 on nuget. There isn't a stable 7.0.0 version yet. However, if someone tries to use our current Aspire component for RabbitMQ with the 7.0.0-alpha.6 version they will get a MissingMethodException (see #3956). Putting a version constraint on now signals to customers:

  1. The new, preview version is not expected to work
  2. We are aware of the problem.

@eerhardt eerhardt merged commit ff9732f into dotnet:main May 29, 2024
8 checks passed
@eerhardt eerhardt deleted the UpdateComponentsDocs branch May 29, 2024 18:02
@github-actions github-actions bot locked and limited conversation to collaborators Jun 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-integrations Issues pertaining to Aspire Integrations packages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants