Nobody except you cares about the CVS revision numbers; they're an internal artifact of the mechanism you use (if you used Git instead, the revision IDs would be entirely different and without obvious sequence).
Instead, you should define versions in terms of releases where you say “this is a configuration of the code that it makes sense to use as a whole”, and it is those versions that you should refer to in documentation, especially for things like deprecation notices. After all, it is those versions that consumers of the API — the people who will be the consumers of the deprecation notices, and the software they create — will see. In terms of your revision control system, release versions are the sort of thing that it is usually best to model with a tag or label.
If you've not yet done a release, you don't need to deprecate anything. If you've got a release in the past, the deprecation notice should mention the next release version. (It shouldn't mention the version that's just released though; that should be regarded as a static artifact.)