There's a reason why the schema changed; deleting the record from the upgrade history should definitely not be the first resort. You should install the cumulative update.
The reason this may happen is that, for example, a cumulative update to Service Pack 'x' may include newer changes than Service Pack 'x + 1'. So when you install Service Pack 'x + 1', you may be missing those newer changes, and thus you may need a cumulative update for the new service pack.
This article is a good overview: https://social.technet.microsoft.com/wiki/contents/articles/32360.sspr-troubleshooting-the-version-of-the-report-server-database-is-either-in-a-format-that-is-not-valid-or-it-cannot-be-read.aspx
The SQL server build number blog can help sort it out (http://sqlserverbuilds.blogspot.com/)
For example, we had this problem when we installed SQL 2012 SP3: we had installed a cumulative update to SP2, then we got the Nov. 2016 security update -- so we had the "CU" version (note that there's two "security update for SQL 2012 SP2": the "GDR" version (if you don't have any CUs installed) and the "CU" version).
If you check out the build list, you see that that security update basically brought us up to SP2 CU14, which if you check the article above, brought us to Reporting Services Schema version 164. So when SP3 was installed, we had "security update for SQL Server 2012 Service Pack 3 GDR, which was based on an earlier version, that only had version 163. So -- as per the article -- we needed to install SP3 CU5 or later to bring us back to the "164" schema version.
