I have a project in which I'm the sole contributor, there isn't a stable API yet and I'm constantly refactoring code, but I still try to denote breaking changes whenever they do happen. Recently however, the repository for this project has attracted some interest and I decided to establish some conventions to make it easier to write changelogs and attract new contributors, so I adopted the Semantic Commits convention, which is similar to the one used by the Angular project.
Both Angular and Semantic Commits specify certain prefixes for commit messages: "feat" for new features, "fix" for changes which fix a bug, "refactor" for code changes which neither add a feature nor fix a bug, etc.
My question is, going forward, should backwards incompatible changes, like changing the name of a public method, be labelled as "refactoring", if it doesn't actually add a feature in the process?
For example, my project exposes a CLI interface, which expects arguments to set values. If I change the parameter name used to set those values, without changing anything else about their implementation, is it better to label that commit as "refactor" or "feat"?
My reasoning is that "refactor" is appropriate, because I'm not adding anything, I'm just renaming an existing method, but I ask because the way "refactor" is described implies it should be used for changes which don't affect the API, but "feature" also doesn't feel appropriate to convey the change. Is there a preferred practice in this scenario?