The purpose of a database is precisely to allow you to keep things separate. So while you don't have to, you can.
The requirement really boils down to what you need, taking into consideration what the best method is to save time wherever practical.
I have worked on a system for which we completely de-coupled database changes from application changes. In fact we made a point of not doing both at once unless necessary (or unless the whole point of the application change was to introduce new capabilities in the database). The reason for trying not to do both at once was to minimise risks of anything going wrong and needing to reverse the installation. The more you change at once, the higher the risk. But that was Air Traffic Control, so we were careful. It all depends on your own circumstances and end user requirements.
The way we resolved versioning is that each database version was also tagged with the application version. Our application versions were such that we knew just by looking at the version numbers whether the database was compatible or not (i.e. major versions were DB changes, minor versions within a same major version were all DB compatible). No matter what your scheme is, you need one that is easy to read & track.