Contract code is permanent. There is no way to alter the code of a deployed contract except by destroying it altogether by the
SELFDESTRUCT opcode (
selfdestruct() in solidity.)
There's four ways, more or less, to cope with this:
- Don't. Just have the contract be eternal, no matter what happens.
- Use some scheme to work around this limitation.
- Create a new contract, and find some way to reconnect to old users/other contracts.
- Create temporary contracts.
Note that some of these bleed into each other--3 and 4 are quite similar.
1 is the second-easiest, since you don't have to do anything. It's also the most dangerous, since it basically hopes that there will never be a critical bug, ever. This is almost certainly a false hope.
2 is a lot harder. There are ways to have the effect of changable contract code. For example, you could put the data in one unchanging contract, then call a library to actually execute it. Here would be my advice on how to do that. However, as I mention, it's not for the faint of heart, and it's probably not worth it on a small scale.
3 is what the DAO would have used to upgrade itself, had it not been attacked. One option is to have a simple contract acting as an entry point to the current, "real" contract.
4 is the easiest, and IMHO, the best, if possible. If no contract has a need for long-term state, then it might be best to flat-out create a new one every time you update. The Ethereum Alarm Clock, as I understand it, simply just has newer and older versions on the chain. There's no need for complicated schemes, and if you do need an older version, it can stick around.
The best question is to ask yourself what you require. Will there be a "final" state to the contract? In that case, you might get away with 1. If there's not, you might be able to use 4. If neither, or if you absolutely need to keep the same address, then it might be time to look into 2 or 3.
EDIT: See also this question for other ideas.