Earlier quoted context omitted.
For most projects it seems like a pretty easy change. You could add new keywords, alias the old methods/commands to them. You don't even have to deprecate them, just make the docs point to the newer terminology. What is easier having to have this conversation EVERY time the term gets used for the rest of eternity, or making the change once and being done with it?
>What is easier having to have this conversation EVERY time the term gets used for the rest of eternity, or making the change once and being done with it? That's not very compelling. Just because certain people make a lot of noise doesn't mean we have to do what they want us to do. >For most projects it seems like a pretty easy change. You could add new keywords, alias the old methods/commands to them. You don't even…
Antirez said if he started a new project it would be named something different. I can only assume some other future databases will will take this approach. Maybe Antirez will write one of them. When that happens now we have a new problem: divergence in the ecosystem.
My preference would be for a big project to adopt a separate term, "secondary", "follower", "replica", whatever. So that when other new DBs look for an "alternative term" there is somewhat of a standard. Really though, that's not even that bad of a problem, because when i say all those terms, "secondary" etc. it's pretty obvious in the context of a DB what i'm talking about.
Do you have to do something __just__ because people are making your life hard? No. Do you have to make a change just because something is technically incorrect? No. Do you have to make a change because something is offensive to a large group of people? Still no. Maybe a better question to ask is, at what point would the tables be turned? What would push you over the edge to say it should be changed?