Versioning everywhere in engineering / ManufacturingLets look at the below bridge analogy to understand versioning in other engineering disciplines.
There was a river and people lived in both the shores. They used small boats and rowed manually to reach other side. All were living happily.
One day some people came claiming that they are civil engineers and they told that they can make the river crossing easy by introducing something called a bridge. People were convinced on the argument that they don't need to spend money on buying boat or boat tickets. They can use their legs which is proven to travel in the land. Some people told why we need new things as the boats are serving the needs. But eventually more people agreed, raised fund and engineers built a wooden bridge which is 1 feet wide and only allows travelling in one direction at a time. Yes they got Bridge V1.
Knot versioningEngineers started seeing their unemployment and started saying cons about what they built recently. They complained that it supports traffic in one direction at a time. Also they complained that people cannot take their cattle through it. They advertised that it, if people can riase more money they can widen the bridge so that traffic can be bidirectional and it can support their animals such as cows. Some people who didn't support bridge earlier told why we need bigger bridge as we can use the existing by waiting for some extra time. But this time as well, more people thought of wider bridge and they raised fund to extend it. Then they got Bridge V1.1. This is the knot versioning model where every user uses same thing which is upgraded
Compatible versioningAfter one year cars started running in the roads and the rich people bought cars first. They felt it difficult to cross the river as the bridge is not supporting cars. They came to engineers and asked them to have some way to take the cars to the other side. This time engineers asked more money and declared that the base of bridge, they had built is not strong enough for cars so they need new bridge. They also told that the same bridge they are building for cars can be used by people who don't have cars too. This time there was not much resistance from the people. They raised more money and built a 6 meter wide concret bridge. This time the fund raising was lead by local city authority and engineers were dealing with authority. After the new bridge is built, they declared that the old bridge will never be maintained. They never demolished the old bridge. Engineers named it Bridge V2.0.
This is compatible versioning where new version support old customers where older version is still there but discouraged to use and not maintained further.
Engineers got the maintenance work on the new bridge as well. After each maintenance they increased the last number in the bridge name.
Point to point versioningNext year authorities decided to start train service between the shores and they contacted the engineers. This time they told that it needs to be new bridge because of below reasons
- Its difficult to upgrade the existing bridge which is already used for vehicles and people. At each and every steps of construction they need to test whether it can support cars and people as it is supporting right now.
- If the new bridge needs to handle single responsibility of trains they can build it efficiently.
- They also told that if they expand existing bridge for trains they may need to close it for 1 month which will be difficult for the people who are already using it.
- They prepared a cost comparison chart between building a new bridge as well as upgrading the existing one. It was clear that new bridge is cost saving.
Engineers got maintenance contract for new bridge as well.
The local authority was running out of funds they raised for bridges. So they declared wooded bridge is not required as most of the people have cars. They called same engineers to disassemble the old wooded bridge and auctioned the wood.
Versioning in Software engineeringIn software engineering, we call the access points as API. Versioning concept is applicable here as well. It is very difficult to decide which versioning method is the way to go. Sometimes it will be cost effective to follow knot versioning where server and client applications can be upgraded together. But it cannot sustain for long and at some point we will be struck. Compatible versioning is little better in terms of cost but after long time, we will not be able to support backward compatibility.
Point to point doesn't held us from stopping new versions. But the cost is always proportional to the versions
The problem here is we don't have a concrete costing/estimation mechanism to compare the versioning strategies. Since we don't have facts it would be always difficult to convince the stake holders on the strategy.
But below is a good link, which explains mathematically how cost can be calculated for versioning API.