Reading the docs I ran into a couple of mentions of problems with introducing new features or changing behavior, with the fear being that varying behavior in clients could cause a fork in the chain.
As I understand it, the fear is justified because of the presumption that two different versions of the software would implement different behavior.
I suggest that this could be remedied by identifying the behavior and hiding it behind an interface. One can then isolate the two conflicting behaviors in different derived classes, and keep running the old behavior in the new version of the client until it detects that more than 1/2 (or 2/3) of clients are running the new sw. The new behavior can then be activated by switching over to the other derived class.
If nobody has the energy to implement a function which keeps a tally of clients versions throughout the network, the switchover could be done manually. E.g. add a check for version number in peers' clients, and if any of them are less than 0.8.6., keep running the old class. If all peers' are 0.8.6 or over, switch over to the new class. Then update to 0.8.4 with the changes and wait until more than half the clients have upgraded. Then upgrade to 0.8.6., in which case the change kicks in all the clients.
Topic: Version control (Read 421 times)
Jump to: