-
Notifications
You must be signed in to change notification settings - Fork 230
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
Remove non-inclusive terms #1073
Comments
We have this planned in phases. You should start seeing naming changes in the next patch release. |
Wonderful, thank you 🙏 |
The main code portion of this was completed in the 0.37.0 release. There is still an issue in OCMock, which we use for some unit tests. We also haven't swapped out the branch names yet. |
Amazing, thank you so much @echo-branch. This means a lot to me and everyone on my team. Thank you for making it a priority. |
@echo-branch I do still see several references to non-inclusive terminology, however. Any chance of a quick 0.37.1 to address some of them? |
Thanks the heads up on the missed comments. Will be fixed. |
Some of them are comments, but several methods still reference "white" lists as well. |
Yea. I totally failed to search for that term. |
No worries, I welcome all progress. Does "white" list/etc. feel like an 0.37.1 type of thing, or do you think it will need to wait for an 0.38.0 release? |
It changes a little used public API so probably 0.38.0 just to prevent breaking. However, I'll try to release that in place of any patch release for 0.37.0. There's also a plan to switch to x.y.z versioning to make it play nicer with Swift Package Manager automatic version updating. I'm leaning towards something like 1.38.0 right now. |
If you're going to redo the versioning it would be great if it can follow semantic versioning. This repo is one of the few we use that doesn't. I'd suggest going to 1.0.0, or 2.0.0 if you'd like to indicate that this is the "second" naming convention maybe. |
Released 1.38.0, just decided to add a 1 and note that our switch was to make life easier with build tooling. This should address Whitelist. Still need to get off the branch name though. |
Can we please get an updated version of the SDK which removes all non-inclusive language? We are focusing on removing such language from our company which extends to all third-party code we choose to use.
Specifically terms such as whitelist, blacklist, master, slave, etc. Would love this to cover actual code of course, but also, comments, branch names, repo descriptions on dependency management central repositories, licensing agreements, etc.
The text was updated successfully, but these errors were encountered: