When I wrote that I was imagining something more significant like a code refactor,
Again, a code refactor is not a change in public API and thus does not constitute a semver major bump.
I’d like to have written a more constructive reply, but with most of your comment consisting of explanations with arguments couched in I’m not interested enough to parse out what is what, sorry. Don’t know why you explain UserChrome.css to me.
The claim wasn’t that a code refactor is always a change in public interface, but that it could constitute a new major version. I listed two examples of when a major version should be incremented, the first being a change in a public interface, the second (erroneously) was a change in a private interface which I then clarified could only apply in the case of a more substantial code refactor, because as you pointed out (and I reiterated and agreed with), private interface changes don’t necessitate breaking changes. It isn’t an exclusive requirement that a public interface has breaking changes in order for the major version to be incremented, only that there be a new major version when that interface breaks introduces breaking changes.
I had to explain userchrome thoroughly in order to demonstrate that it is a public interface and differentiate it from the gui. I assumed it wasn’t intuitive because you missed it when I provided it as an example initially and was accused of avoiding that point.
The first sentence of each paragraph addresses which point it argues other than the userchrome demonstration which follows from the prior paragraph and only addresses your userflow vs interface question in its conclusion.
Again, a code refactor is not a change in public API and thus does not constitute a semver major bump.
I’d like to have written a more constructive reply, but with most of your comment consisting of explanations with arguments couched in I’m not interested enough to parse out what is what, sorry. Don’t know why you explain UserChrome.css to me.
The claim wasn’t that a code refactor is always a change in public interface, but that it could constitute a new major version. I listed two examples of when a major version should be incremented, the first being a change in a public interface, the second (erroneously) was a change in a private interface which I then clarified could only apply in the case of a more substantial code refactor, because as you pointed out (and I reiterated and agreed with), private interface changes don’t necessitate breaking changes. It isn’t an exclusive requirement that a public interface has breaking changes in order for the major version to be incremented, only that there be a new major version when that interface
breaksintroduces breaking changes.I had to explain userchrome thoroughly in order to demonstrate that it is a public interface and differentiate it from the gui. I assumed it wasn’t intuitive because you missed it when I provided it as an example initially and was accused of avoiding that point.
The first sentence of each paragraph addresses which point it argues other than the userchrome demonstration which follows from the prior paragraph and only addresses your userflow vs interface question in its conclusion.