style: migrate from slave/master terms to primary/replica#6324
style: migrate from slave/master terms to primary/replica#6324imnotjames wants to merge 1 commit intotypeorm:masterfrom
Conversation
imnotjames
force-pushed
the
chore/primary-replica-naming
branch
from
7da4b4d to
db69a43
Compare
imnotjames
changed the title
imnotjames
force-pushed
the
chore/primary-replica-naming
branch
from
db69a43 to
61108ac
Compare
|
I did my best to ensure this wouldn't break existing code that may rely on the previous termonology. However, if we wanted to make this into a breaking change that could be arranged. :) |
imnotjames
force-pushed
the
chore/primary-replica-naming
branch
from
61108ac to
ccfff84
Compare
this change updates terminology to "primary"/"replica" more inclusive terminology can lead to a more inclusive project the terminology master/slave is considered non-inclusive by many and most databases that this project uses are also migrating away from the terminology this leaves the original "master" and "slave" terminology in place but marks them as deprecated & points them at the primary/replica terminology. at the next breaking change branch these can be removed with a warning about the breaking change in the changelog
imnotjames
force-pushed
the
chore/primary-replica-naming
branch
from
ccfff84 to
f537cf5
Compare
|
Unfortunately this is a breaking change, and we can't do it right now because it will break user code. But in the future versions, I'm sure we'll apply these changes. |
|
This is a breaking change? What can we do to make it less of a breaking change? I did what I could to ensure the changes wouldn't cause backwards compat breakages, thought it had worked per tests. |
|
Either way, though, thanks for looking at it! Looking forward to when this change can be made. Happy to help out with it against whatever branch is the next breaking release. :) |
|
I'll close this for now so we don't clutter up the pull requests with things that aren't gonna be merged in right away. |
2 participants
this change updates terminology to "primary"/"replica"
more inclusive terminology can lead to a more inclusive project
the terminology master/slave is considered non-inclusive by many
and most databases that this project uses are also migrating away
from the terminology.
this leaves the original "master" and "slave" terminology in place
but marks them as deprecated & points them at the primary/replica
terminology. at the next breaking change branch these can be removed
with a warning about the breaking change in the changelog