Versioning is one of those many necessary evils of software
development. Versioning allows software development to continue to make it
better by improving stability, add features and overall polish the end product.
At the same time, it also leads to any number of confusing scenarios (for both
developers and end users) because not everybody can have the ‘latest’ and
‘greatest’ all the time.
Here is an example, and a real life one. Let’s say you buy a
water bottle (version 1.0). For that water bottle, you buy a stand, which is
compatible with version 1.0. You have been using this for a while now, and
things are fine. However, after some time, you find out that the cap on the
water bottle keeps sliding out. Just like you, other owners of the water bottle
are facing a similar issue. Eventually, the water bottle company releases a new
cap. You buy the cap (since the cap is firmly a loosely coupled component of
the water bottle) and find that it works just fine with the existing water
Since this improvement, the water bottle is now version 1.1
(with improved cap that won’t fall off). Everything is still hunky dory. Then,
something something happens, and the water bottle company releases a new
version with improved base. So, all new water bottles are now version 1.3.
Since your existing water bottle (version 1.0) is getting old, you buy the new
version water bottle. However, you find out to your disappointment that the
improved base of the new water bottle no longer works with your version 1.0
water bottle stand.
The dilemma here is that you water bottle stand (although
old) is still in good shape and you have no practical reason to throw it away.
However, your new water bottle (with all the new bells and whistles) does not
work with the existing bottle stand. That means, you have to throw away your
perfectly functional bottle stand and buy a new bottle stand (which is
compatible with version 1.3). Of course, this does not mean you can happy.
That’s because, next year, the same company may release a new water bottle with
a much improved base, and that means you are once again back to abandoning
perfectly working stuff for the latest stuff. And the cycle continues.
Anyway, hope that explained to you the concept of versions.
So, dot net (which has been around for more than 15 years now) also has many
versions. There is a strong connection between the version number of asp dot
net and the libraries it contains. I am going to assume that you know what
libraries are. If not, read one of our blog posts about it, right here.
You see, each version of dot net platform contains a set of
libraries. This is just like that water bottle, which has many features
attached to it. As and when Microsoft discovers something new, it will test it
and then add it to the next release (with a new version number) of the dot net
platform. That means, each time you see a new version released, you can expect
something new feature that is designed to make your life better.
Although I have exaggerated things with my water bottle
example, companies like Microsoft don’t let things to so bad when new versions
are released. Microsoft almost always ensures that when a new version is
released, the older stuff is still perfectly functional. Suppose you built an
application with version 3.0 and the current version is 4.1. Your application
will still happily run because 4.1 would have preserved everything that made
3.0 application run in the first place. A good example for this would be games
that run on windows. Many games that were originally designed to run on windows
XP can still run on windows 10, with minor modifications. So yeah, with
Microsoft you can be sure that stuff will keep running, most of the time.
Now, a question that will bother developers is, should they
constantly upgrade themselves to newer versions? The answer is an absolute yes.
However, developers will (sometimes for real reasons) will complain about the
constant upgrading of skills. Unless it is a major revision (like 3.X to 4.X),
you will only need a few hours of reading to figure out what is new in the new
version. Further, minor upgrades usually add minor components which may not be
relevant to your current or even future projects.
For instance, there is a lot of talk about replacing HTTPS with
some other, more secure web technology. Taking this into account, Microsoft
might release a new version of asp dot net to work with that. So, you probably
need to learn how to use those libraries by using msdn and stack overflow.
However, if the project you are currently working at your client has no need
for this new security technology, then knowing or knowing about the latest
version of asp dot net will be a moot point.
At the end of the day, it comes down to this. When you are
assigned a project, you will be informed which version of asp dot net you will
be working on. Unless you haven’t learnt anything new in the last 3 years, you
are probably in the safe. You may have to learn some new libraries but your
existing knowledge will suffice. Over time, depending on what or where your next
project might take you, upgrade yourself to the relevant version of asp dot net
(by looking at the release notes of msdn) and be ready with it.
Follow me on twitter, facebook and instagram for more updates. Thanks!