When the new upgrade is installed, the class would bear the new API version as well for that subscriber. Depending on the situation, this may or may not have disastrous consequences.
Global Classes
If the code is global, and subscribers are actively calling your code, the version change might introduce new features in to their code unintentionally. This can cause very subtle bugs like this one that they might need to fix.
Public/Private Classes
Since those classes can't be accessed outside your own package, it is usually safe to update the API version. However, do be aware of bugs like the one I linked, above. Make sure you have unit tests in place to make sure that updating the API version doesn't break any of your code. Also be aware of any dependent classes and their versions, as well; you may be forced to update many different API versions.
Talk To Your Subscribers
You may want to send them a survey or something to see if they're using the code in question, if necessary. Remember, packages can only be upgraded, not downgraded, so if you break a subscriber's org, you're going to have to be prepared to patch it back.
Consider Patching
Instead of developing the new feature first, create a patch, update the API version, and push that to your subscribers. Then, if it breaks stuff, you can always patch it back. This is arguably easier than forcing everyone to potentially update twice if you have to roll back the change.