Closed agross closed 8 years ago
The title is stating a fact. Yes, it looks like the nuspec wasn't updated when the last version was bumped. But what this issue fails to mention is what the problem is. Are you getting errors? Is it just a matter of updating the Windsor package? What's the issue here?
What if Windsor 4.0 comes out with breaking changes?
What if Windsor 4.0 comes out without breaking changes, at least not for the APIs that we're depending on. Then we'd have to release a new package just to update the metadata. Thanks, but no thanks :smile:
When your dependency manager follows a "min" strategy to resolve packages, you'll get 3.2.1. Without further work (binding redirects), your program will fail to run because N.B.Windsor wants Castle.Windsor 3.3, but sees 3.2.1.
What if Windsor 4.0 comes out without breaking changes
I guess you could argue both ways. OK, I'll accept that for now and have Paket follow a min version strategy (and always take the oldest dependencies).
Yes, it looks like the nuspec wasn't updated when the last version was bumped.
If you want to remove that error for future releases, Paket has a nice feature to construct the nuspec dependencies from your actual paket.dependencies
file.
This was updated a while ago; https://github.com/NancyFx/Nancy.Bootstrappers.Windsor/commit/4ceffda2f947a1e9e035dc587d1c0514bf8eafbd
I hope the title says it all.
I suggest also not to define an open version constraint in the nuspec as it's currently the case (
>= 3.2.1
). What if Windsor 4.0 comes out with breaking changes? If you use a package manager like Paket you'll find issues with version constraints very often.