For a linear sequence of schema changes, some database frameworks provide schema migration support.
There’s some info in the database about its current schema, and the framework will apply necessary migrations to bring it to the schema version supported by the version of the app used.
However, this doesn’t work well when you intend to support V3 including schema changes in that version, so if possible at all, avoid that. It would also make it much harder to support migrating from any of the possible V3 schema versions to the currently supported V4 schema version when the customer decides to switch.
If your version 4 is totally different from version 3 and automated migrations are not an option, assigning it a new schema name might alleviate the issue of parallel support for both versions. You’re essentially supporting two different apps with independent schema change histories, which sometimes may be a sensible choice, as it allows you to leave historical cruft behind you.