thank you guys
who will do the npm update? 😇

I'm not sure if you were planning to do this in a separate change, but i noticed the requiredAngularVersion prop wasn't updated in the package.json from 13, which i believe would create the wrong peer deps on build. (Would be super grateful if you used ^14.0.0 || ^15.0.0 for that)

I don't know what happened, but the package.json inside the npm package is not updated properly.

Yes, as @michaelfaith rightfully points out, I missed a field in the update (too many squashes, rebases, etc trying to get this PR to ship). I've cut #1417 to correct this. @michaelfaith while I understand your desire to make future upgrades easier, I can't quite stomach the possibility that there will be a breaking change in v15 that we are not prepared for in advance. Therefore, I'm not taking that change, but will try to be more proactive in the future about preparing for releases.

@CaerusKaru fair enough. I'll try and make one more plea for it, but at the end of the day, it's your call to make. It just seems like, as a heavy user of this product for years, the only time i ever come to the repo to look for or log issues it's because of the restrictive peer deps. I've never had to come here because of a breaking change. Not to say that that won't happen, but if more of your energy is spent on dealing with reports of peer dependency issues than on some potential future breaking change, then relaxing the peer deps to reduce the upgrade friction would make things easier on everyone (yourself included). It would give you time to make these updates at your leisure and not feel like you're putting a fire out. Also, if the Angular Material project, as large of a project as they are and as large as their user base is, feels like it was an acceptable risk for them, i feel like it would be for this project too. Especially since this project is far less susceptible to be impacted by breaking changes as they are. Anyway, just wanted to try and make my case one more time. Appreciate the work on this.

Let's just say that I expect the number of possibly impacting breaking changes to increase in the next few versions, specifically targeting APIs that we use in this library (and that angular/components may not use). On top of this, the components team has a full-time staff that can adjust, discuss, and react quickly to breaking changes as they're being planned and rolled out. While I am also privy to the same discussion and planning, I am not a full time resource for this project, as much as I sometimes wish I could be. So while I understand your position as a longtime user, it's just not something I can realistically put on the library right now. If the Angular team changes their position on the support story for this repo, that's of course something we can re-examine.

Fair enough. Appreciate the thoughtful reply and your continued efforts on the library.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}