Skip to content
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

Open
tinder-owenthomas opened this issue Nov 13, 2020 · 12 comments
Open

Remove non-inclusive terms #1073

tinder-owenthomas opened this issue Nov 13, 2020 · 12 comments

Comments

@tinder-owenthomas
Copy link

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.

@echo-branch
Copy link
Contributor

We have this planned in phases. You should start seeing naming changes in the next patch release.

@tinder-owenthomas
Copy link
Author

Wonderful, thank you 🙏

@echo-branch
Copy link
Contributor

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.

@tinder-owenthomas
Copy link
Author

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.

@tinder-owenthomas
Copy link
Author

tinder-owenthomas commented Jan 26, 2021

@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?

  • Whitelist
  • Master
    • I appreciate that this one may need to wait until there's time to rename the default branch

@echo-branch
Copy link
Contributor

Thanks the heads up on the missed comments. Will be fixed.

@tinder-owenthomas
Copy link
Author

Some of them are comments, but several methods still reference "white" lists as well.

@echo-branch
Copy link
Contributor

Yea. I totally failed to search for that term.

@tinder-owenthomas
Copy link
Author

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?

@echo-branch
Copy link
Contributor

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.

@tinder-owenthomas
Copy link
Author

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.

@echo-branch
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants