How does Bitcoin deploy new features and manage different versions compatibility?
For example if a new feature is added to Bitcoin, how is that then deployed and managed? That is, how is everyone on the network not forced to upgrade when a new version is available?
If an upgrade/update is not forced, how does Bitcoin manage different versions of Bitcoin on the network? Is there a minimum required version somehow distributed amongst the network?
There are two different kinds of changes, that have to be deployed in different ways:
In order to maintain backwards compatibility, i.e., allow people to upgrade when they feel comfortable, and not being impacted by the change, Bitcoin currently limits itself to perform only soft-forks. Transactions and blocks that are valid under the new rules are also valid under the old rules, hence non-upgraded node will also count them as valid, and there is no lasting fork between the versions.
In a hard fork the upgraded part of the network accepts something that looks invalid to non-upgraded nodes, so we have a persistent fork, in which upgraded nodes have their own blockchain, and non-upgraded nodes will have theirs. This is a dangerous scenario since now there are two networks, from one initial network, and there can be some interference between them (e.g., replay attacks). This is what happened in the Ethereum vs Ethereum Classic fork.
An example of soft-forks is the segwit proposal: transactions will still be valid for non-upgraded nodes, and they'll be able to update their local view of the ledger (though they may not be able to fully verify a transaction's validity) and upgraded nodes enforce that the extended validity rules are respected. On the other side a blocksize increase is a hard-fork, since non-upgraded nodes would not accept larger blocks, staying on a small-block fork, while upgraded nodes would accept them, creating an large-block fork.
These are the fundamental two kinds of updates, though there are some mixed versions, and the classification is often not that clear (due to the complexity of the system).
Another way of introducing new features is layering additional functionality on top of the basic blockchain, e.g., Lightning or Sidechains. In these we do not attempt to modify the blockchain, which would require opt-in from a large percentage of the community, instead the functionality is implemented in a smaller context, requiring only participants to opt-in, allowing interested parties to either use it or not.
(disclaimer: I am an implementor of the Lightning protocol)