-
Notifications
You must be signed in to change notification settings - Fork 479
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
Update Component docs #4270
Conversation
- Add information on versioning and breaking changes from dependencies - Add EndToEnd test information to the checklist
Co-authored-by: Sébastien Ros <[email protected]>
Co-authored-by: Ankit Jain <[email protected]>
There was a problem hiding this 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- The new, preview version is not expected to work
- We are aware of the problem.
Co-authored-by: Dan Moseley <[email protected]>
Microsoft Reviewers: Open in CodeFlow