Do Versions Matter?

By William Peterson, MapR

Naming is hard. Once you’ve chosen a name and your product or solution is out the door, it’s still not over. What do you call the next version? You only need to look at Apple’s latest iPhone release to realize how difficult version naming can be.

For iPhones, Apple has numbered its major releases and appended an “S” to the second release of each iteration. This worked well enough until the iPhone X update, which, following Apple’s own naming conventions, was labeled XS.

The name itself created several problems. First, XS is the abbreviation for extra small, something Apple doesn’t want consumers to associate with its latest product. Second, how do you pronounce it? Do you pronounce the actual letters XS, which sounds terrifyingly close — and some would argue accurate given the hefty price tag — to “excess”? Or is it “10 S” like “tennis,” with the XS Max sounding an awful lot like a round at Wimbledon?

But do versions even matter anymore? In an increasingly agile deployed, SaaS-first world, release and version numbers really don’t. Think quick: What version of macOS or Windows are you on? In a world where development teams push SaaS solutions every two weeks, does v14.11.5 mean anything to anyone? How about v14.11.6?

Still don’t believe me? Think about your cable box. Are you running the most up-to-date version of your provider’s software? You have no way of knowing, but the point is, you don’t need to.

The Age Of Agility

In this age of agility where we expect real-time results from data, it follows that we expect real-time results from software too. With SaaS, gone are the days of major releases every six months with minor updates and bug fixes in between. The ease of cloud deployment means updates can be shipped as soon as they work. There’s no reason to hold onto updates for months at a time until the next major release date. As a result, releases are happening daily, weekly, or monthly on the fly.

Often, the end user has no idea these updates are happening, nor should they. From their point of view, updates are largely invisible so why keep track of them? Release numbers are no longer meaningful — if they ever were.

A Better Approach

Though releases need to be tracked internally, traditional versioning represents old school thinking. Release 16.2.1, which is replaced two weeks later with release 16.2.2, is not meaningful for most users. So why do we insist on doing it? We still do it in part because it’s what we’ve always done. We need to find a better way moving forward. We need a more agile approach.

There are a number of ways to reinvent the version number when announcing your product to the public. The simplest and perhaps most useful approach is using a date-based versioning system such as Fall 2018 or Spring 2019, much like Salesforce.com uses.

Want to get more creative? Use a theme-based system like Apple’s California place names for their OS (e.g., Sierra, Mojave) or Android’s desserts names (e.g., Cupcake, Donut, Eclair, Gingerbread). Certainly these names are more memorable than an endless string of version numbers.

Though minor updates are tracked through your website, support, and community, they don’t get their own name externally. In the SaaS model, they just don’t need one.

SaaS And Ensuring Application Availability

There are some risks with the SaaS approach. Historically, software was only shipped every six months or more because of the extensive testing required with each new release. QA needed time to make sure nothing broke with each update. With the advent of real-time software, however, you’re shipping faster because customers are facing more competition and expect faster upgrades. With these razor thin development cycles, you need to be able to be able to correct any unforeseen performance issues immediately and without disruption to your customers.

If you have broad API support and developer tools, you must ensure you’re not breaking the application when you’re making these updates. When pushing updates in an agile development environment, you need strong data management tools to ensure application availability. Some of the key components of data management required to support SaaS include the following:

• Snapshots and mirroring. As development cycles decrease, so too does test time. If an update broke your customer’s system, you need the ability to roll back an update. Snapshots and mirroring help you do this quickly and accurately.
• Multitenancy. An important part of application availability is making sure the correct data is available for the right people – that manufacturing can’t see finance’s data. Maintaining these privileges is essential. You want to make sure you don’t break it.
• Security. If security is part of your solution, you must maintain the integrity of any security policies already in place when you ship this quickly. Think of data access, government regulations, and fraud detection — to name a few — that depend on robust security policies.

You want to move fast but not screw up anything that’s working. If you have the right platform, you can roll back quickly to where you were, averting any disasters.

What’s In A Name?

As Shakespeare wrote, “That which we call a rose by any other name would smell as sweet.”

What your product is called is less important than how it works and how seamless your updates are. The whole point of SaaS is your software is agile and responsive, so you can meet your customers’ ever-changing needs.

With SaaS, we have moved beyond version and release numbers. Data platforms that provide robust API and developer tools allow access from any place at any time have rendered versioning obsolete.

Any great ideas for naming? I’d love to hear them in the comments below.

About The Author

William Peterson is VP, Industry Solutions for MapR. Prior to MapR, Bill was the Director of Product and Solutions Marketing for CenturyLink. Prior to CenturyLink, Bill ran Product and Solutions Marketing for NetApp’s Analytics and Hadoop solutions. In addition to his marketing role at NetApp, Bill was the Marketing Co-Chair for the Analytics and Big Data committee, SNIA. Bill also has served as a research analyst at IDC and The Hurwitz Group, covering the operating environments, content management and business intelligence markets. Bill did his undergraduate work at Bentley University, and has completed MBA coursework at Suffolk University.