In general future versions of Ethereum shouldn't break existing contracts. Future upgrades should respect the need for existing contracts to keep working. If they do, it is unlikely that you will be able to fix your contract.
However, there are certain aspects of the system that may well change, and you should avoid relying on those if you want to minimize the chances of your contract being broken by a future protocol upgrade. A couple that spring to mind:
- Don't try to measure time by counting blocks. Sometimes people will suggest using block numbers as a proxy for time, because of some issues with the trustworthiness of timestamps. (See Solidity: Timestamp dependency, is it possible to do safely? for discussion of these issues). But the length of the block interval is already varying due to the ice age, and it could change radically in the transition to proof-of-stake.
- Don't rely on gas prices remaining the same. Gas prices are hard-coded in the protocol, and listed in the yellowpaper. However, they were decided based on the approximate relative cost of performing different operations, and that in turn depends on the performance of the hardware and software they are run on. There has already been a hard-fork that changed the price of some operations that had turned out to be more relatively expensive than intended, making DoS easier, and they may well be repriced in future.
Finally, if you are able to create escape hatches in your contract, they can protect you problems caused by both protocol upgrades and new discoveries of security issues. These often come with trade-offs in the form of extra trust requirements, but sometimes the trade-off is worth making. For example, some contracts give developers or curators an ability to freeze the contract and return user funds in emergencies. Others allow wholesale upgrades of contract logic - see this answer for discussion of how to do this: Upgradeable smart contracts