-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[META] Cleaning up obsoleted items #1194
Comments
Alright, quick brain dump:
The $64000 question of course is "how long should these be obsolete for before removing them?" I might be being totally arbitrary here, but 2 releases feels like a good number - just in case callers happen to skip a release. We've been rather slow with releases lately (~1 month and ~2 months between the last three releases) but if we get moving to a more frequent cadence of releases (hint: yes, we should) then we can re-evaluate this and perhaps move to a time-based approach. |
brain fart: Should we include the release in the obsolete message? (the release that is current when the change is made || a reviewer can just say - add in "in release x.x.x) |
I agree, but for devil's advocacy do accepted (& actually used) guidelines exist for this kind of thing? |
Maybe? Having the release number there may mean they'll go and read the release notes - but perhaps the details in the message are enough for them to understand...
"It depends" is really the best answer I can come up with, and this probably comes down to support lifecycles. On one hand, $vendor may need to support obsolete features in an API until the next major release. On the other hand, some OSS library may choose to ignore SemVer and arbitrarily introduce breaking changes because move fast and break stuff. Technically we're pre-1.0 so SemVer is not very opinionated about this, but I'd favour being more conservative in general. In my mind 1.0 is having GitHub v3 API support covered and some necessary infrastructure changes in place - but we can act like post-1.0 right now with respect to obsoleting changes... |
Sounds good to me. |
So given that theres a pretty massive gap between the ones that are 200+ days since obsoleted, and a bunch sitting at around the ~80-100 mark... we should be pretty safe to remove all the really old stuff? 🔥 these
And keep the following for now
Happy with that approach for .20 release? |
If the answer is yes, I would like to do that PR |
Yes, very happy |
ApiConnection.GetRedirect() depends on IConnection.Get(... allowAutoRedirect) It currently did this: |
@M-Zuber I think we should drop usages of the |
Im thinking that we should just 🔥 the
|
👋 Hey Friends, this issue has been automatically marked as |
Just opening a discussion to review the items marked
[Obsolete]
, since most of them will have been more than 3 months old by the time of the next release (and many of them are 1 year+ old too)... it must be time to 🚀 🔥 some of them 😀We've currently got 80 occurences across 39 files, and by my (manual count) about 14 actual functional areas.
Here's a list of the areas and the number of days since they were obsoleted
And here's the raw "Find in Files" output
The text was updated successfully, but these errors were encountered: