I would imagine there should be an inherent relationship between these branches that ought to address the problem of version numbers.
I would envision you might do something like merge production-ready code from the dev branch to the release branch, then perform a Maven release (via Jenkins or manually). This automatically rolls the version numbers to the next build. So you merge code 1.4.7-SNAPSHOT to this branch, perform the release and cut version 1.4.7, and Maven automatically rolls your working copy to 1.4.8-SNAPSHOT.
Updating Baseline (optional)
If you're not already using your trunk (or baseline branch, etc) as a place for your releases, you should be updating the trunk as soon as you complete a release. This means your version numbers are getting updated as well. This step might be moot if you just consider the release branch to be the baseline.
Up-merge from Baseline to Dev Branch
It's essential that your development branch stay up to date with the actual production code. You need to merge the code from the baseline (or release branch, depending on implementation) up to your development branch. This is important in your case because it means the pom changes that occurred during the release process, which changed the version to 1.4.8-SNAPSHOT, are brought to this branch.
Based on reading I've done (as well as processes with in my organization), this seems to be a pretty standard and effective use of Maven releases and snapshots, and rather than maintaining completely disconnected version numbers on different branches, it's easy to tell that any 1.4.7-SNAPSHOT build was in fact an immediate predecessor of the 1.4.7 release. They're related. I would go so far as to say if you're not merging back and forth between these branches, you're doing both SCM and Maven versioning wrong, and you're putting yourself at risk for developing against code that doesn't match production, re-introduces bugs to production, etc.