9 out of 10 open-source experts advocate frequent releases. We, the simple people, don’t know better and should listen to the experts. Sadly, we simpletons still don’t know how to read and so the fine print eludes us. While we all may be good and obedient developers, the users don’t care for our frequent releases squashing our colossus bugs and featuring our shiny new toys. As frequent our releases are as frequent the reports of bugs long ago fixed and features that shined and sparkled at ancient times but are now filled with rust.

Ghost versions of the past haunt us daily while users refuse to upgrade. Our innovative forefathers, suffering immensely from this plague, had uncovered the great potential of automatic updates. No longer is the user able to flee his ordained destiny. Fate shall pop-up and fulfill itself even with the absence of user interaction.

But even this sparsely applied method carries its own set of fine prints. Boiler plate implementation includes a web server containing the latest version number or even a server-side script that ever so nicely checks for the user whether his version is expectedly old. As with everything else, here too success brings failure. As faithful users gather their masses around our monthly-polished releases, the web server begins to break down. Most web servers, especially those that poor open-source developers can afford, do not offer load balancing and will easily succumb to the sheer amount of bandwidth generated by thousands of users performing even the simplest of GET requests.

Enter DNS. The Domain Name System is a distributed and globally cached system that basically maps domain names such as nsis.latest-version.org into numbers such as 2.36.0.0. And it gets even better — foreign sources report there are free DNS servers out there, waiting to be used. Services such as dyndns.org offer a simple HTTP based API that sets new IP to a free domain name. Creating a new version notification service is as simple as creating a new free domain, updating it every time a new version is released, calling inet_addr when the client-side loads and comparing the result to the current version.

This free and simple solution provides many advantages over conventional HTTP based version check.

• Automatic load balancing with servers all over the world.
• Simple code with no need for complex HTTP libraries.
• No need for relatively heavy HTTP operations for both client and server.
• HTTP proxies do not get in the way.
• Firewalls and the entire security fiasco usually overlook DNS.

And as always, there are disadvantages.

• Updates take time to propagate.
• Only 3 bytes of information.

Make sure you set the first byte to 127 to make sure the IP associated with your update domain is invalid. This way, whoever is at 2.36.0.0 won’t get any unwelcome traffic.

I am probably not the first to think of this, but it is a cool idea nonetheless. I’m so going to implement this for the next version of NSIS! 🙂