Not so. Adding a new column is not a breaking change for reads, and may not be a breaking change for writes unless the new column is required, has no default value, and cannot be NULL.
Take for example a GetUserStatistics() call which provides a list of userids and the users last login date.
A client might be using this list to get statistics on system usage.
If you change the codebase to add the concept of a test user and add an isTestUser column to GetUserStatistics() you have broken the contract with your users.
You had an implicit contract based on shared understanding of the data.
Now of course to correctly determine user usage statistics you need to exclude the test users by checking the new column.
And I'm not discussing changing the schema, but the data contained with the data structures.
When transforming the schema, you frequently have associated changes that you apply to transform the data from one form (in the 'before' schema) to another (in the 'after' schema). These transformations are code that can have bugs like any other.
In cases like these you can have data that is in the right format, but isn't correct, and can need a second change (to the data only) to correct it.