fix: Remove upper-bound version constraint from SCI

[austindrenski]

Fixes: #170

See: #136, #137, #170

---

Anticipate similar arguments/discussion as in #137, but opening as a companion to #170 because this is causing me real-world grief today 🙃

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (c1a189a) 94.73% compared to head (dbaa1ee) 94.73%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #171   +/-   ##
=======================================
  Coverage   94.73%   94.73%           
=======================================
  Files          23       23           
  Lines         931      931           
  Branches       93       93           
=======================================
  Hits          882      882           
  Misses         29       29           
  Partials       20       20           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[beeme1mr]

No idea why the code coverage report is failing...

At any rate, I'll add the people from the referenced thread.

[toddbaert]

@kinyoklion Has you opinion on this changed at all since #170 ?

[austindrenski]

Bumping because this is unfortunately causing an increasing amount of developer friction inside my org.

Including this package breaks our in-house source generators when invoked by IDE-triggered design-time builds in such a way that my normally strong msbuild-foo has thus far been unable to combat.

I would like to get some movement on this today, otherwise I'm looking at needing to publish a forked package to appease a growing horde of angered devs. (This is, of course, a me problem, so I don't mention it to force a decision one way or the other, just to say that it would be nice to hear from folks on whether this is a quick action or something I need to self-serve for the foreseeable future.)

/cc @toddbaert @kinyoklion

[austindrenski]

Note: just saw #166 (f5fc1dd) land, and pretty sure the upper-bound constraint on System.Threading.Channels will end up causing the exact same problem.

Can someone catch me up on why we're going out of our way to set upper-bound constraints in the first place?

Originally, I assumed it was something specific about System.Collections.Immutable that we were depending on (e.g. internal impl details, sketchy reflection, etc.), but now noticing that we do this in a bunch of places, so wondering if this is just an artifact of someone's repo template, or if there's some bigger concern that I'm missing 🤔

[toddbaert]

Can someone catch me up on why we're going out of our way to set upper-bound constraints in the first place?

Originally, I assumed it was something specific about System.Collections.Immutable that we were depending on (e.g. internal impl details, sketchy reflection, etc.), but now noticing that we do this in a bunch of places, so wondering if this is just an artifact of someone's repo template, or if there's some bigger concern that I'm missing 🤔

I think it was just out of fear of breaking changes in further releases of these dependencies, but I think I'm on board with just removing the upper bounds.

[toddbaert]

@austindrenski I've removed the upper bound on System.Threading.Channels as well.