SemVer compliance about pluralize

[blakeembrey]

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API

The words are part of the public API, and the word changes are backward incompatible.

[blakeembrey]

Any change to a pluralization is most definitely a major change. If this is used by a database and happens to use a word that has now change, it has broken their project. I'm going to keep using major versions for this reason, I'm not sure that I should do minor or patches lest it be used in a situation where it's assumed the change won't break for anyone.

[blakeembrey]

I'm going to close the issue, but feel free to continue the discussion. I would love to have more data. Since the words are part of the public API and any pluralization change can break a dependency (imagine deploying an update to your server and because of a plural change your app is broken - in the case of ORMs or auto-generated servers) I'm going to continue with major version changes (as defined by semver). If you disagree, feel free to lay out your arguments here - it's definitely not the end of the conversation.

Even things as innocuous as TypeScript interface generation that may be using a word that was changed in a major release, resulting in application compilation breaking.

[maschwenk]

After I opened issue I thought about it more and came to a similar conclusion.

The most obvious comparison I can think of is ActiveSupport in Rails. If pluralization rules changed there, your application could start referencing differently named tables and therefore it is definitely a breaking change. I'll circle around if I find a good example in the ActiveSupport changelogs.

Thank you for your thoughtful response.