Hi @miohtama,
I am not sure how future proof you can make your token (without making it upgradeable), though it is definitely worth looking at whether enabling GSN for your token meets the needs of your intended use case.
As an ERC20 you need to consider the approve and transferFrom pattern. As well as making your token GSN enabled, any contracts that your token holders interact with using their tokens that you want them to use without having Ether will also need to be GSN enabled.
I would start with looking at the documentation: Sending Gasless Transactions.
You would need to make your token a GSNRecipient and have a GSN Strategy (decide which relayed calls you want to pay for).
I would suggest looking at GSNRecipientSignature as this offers a lot of flexibility. If you used this strategy, you may want to add functionality to allow you to change the trusted signer if you needed.
There would be some extra overhead on deployment, and I assume a small amount on checking msgSender (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.0.0-beta.0/contracts/GSN/GSNRecipient.sol#L88).
You could check these overheads.
Overall, I think making your token GSN enabled is worth considering to have the option of allowing transactions via the GSN. I assume that other meta transaction solutions wouldn’t be incompatible (though you would want to check),
You may want to look at creating an ERC777 token (no need to do approve and transferFrom in two separate transactions). See the documentation for details: https://docs.openzeppelin.com/contracts/2.x/tokens#ERC777
Something else to consider, OpenZeppelin Contracts 3.0 is in beta and uses Solidity 0.6. OpenZeppelin Contracts 2.5 uses Solidity 0.5.
I would also look at other meta-transaction schemes, including smart contract accounts, though it really depends on your use case of how your token holders use your token.