What if we approached software applications the same way we do with TV series? Our favourite shows come in neat packages : seasons and episodes. Each season typically advances the plot, delves into character development or explores a central theme, while episodes are small chunks that progressively unfold the story. The naming convention is straightforward. Season one’s episode 12 is shortened S01E12. It’s, in essence, a versioning scheme. Could we use it for versioning software?

Versioning

The standard for versioning software is Semantic Versioning. The convention is to use a simple format consisting of three numerical components: major.minor.patch (for example, 1.2.14). The major number represents the main version of the software, while the minor number marks intermediate updates, which are small features of a major version. Lastly, the patch number is for bug fixes and security updates.

We see this numbering in many places : app stores, release notes, and package managers. Semantic Versioning is excellent for computers and package managers like NPM, where we must pinpoint versions and signals breaking changes precisely. However, it is meaningless for Humans. How we version TV series could inspire us to create a versioning scheme for Humans.

Storytelling

Remember when software was sold in cardboard boxes  and CD-ROMs ? The Internet has drastically changed our relationship with software. We started calling a piece of software an “app”. Apps are distributed on App Stores, and developers can push daily updates if they wish to. Apps have become dynamic and don’t exist solely on your computer. Indeed their content can change daily, and they can offload computations to a “cloud”. Also, the speed of change has increased considerably. Apps must be updated whenever their platform (e.g. macOS) changes APIs or deprecates features.

Software is never finished.

Considering all those changes, we must ask a question. Perhaps we are still treating software as the thing sold in a box  and users as people wandering in a shopping mall? What if we started to weave users into the story of an application ? Users could become fans who anticipate new features and development.

Introducing Story Versioning

Story Versioning is a framework for defining roadmaps and releasing software around seasons and episodes. I’m not advocating using Story Versioning instead of Semantic Versioning but complementing it. With Story Versioning, we need to shift how we think about roadmaps. Building software and creating updates becomes a story split into seasons and episodes. A season has a theme or a major story development. A season could focus on performance and maintenance. Another could be focused on a new feature. Each episode in a season will participate in advancing the plot. How do you deal with security patches ? The answer is to release them in a bonus episode !

Using seasons opens a few possibilities for communicating and engaging with users. Here are some examples. Andy works is a set of productivity apps that works with seasons in mind. Every season brings new apps and artist-designed skins that you can apply. Releasing new goodies and skins keeps users’ interest and engagement alive. Another example; is Fortnite, an evergreen game that uses seasonality to introduce new play methods. During Halloween, the game will display pumpkins and other decorations. The passing of time and unique memories creates history and a sense of bonding between players. It’s an exciting concept that we could use to engage users.

Conclusion

The Internet has transformed our relationship with software and the way it is distributed. Software is never finished. It has a streaming nature. The way we traditionally version software makes sense for computers, but it is not human-friendly. Treating the evolution of a piece of software and its roadmap as a story could help communicate with users and bring more joy, anticipation and enthusiasm. Using the mental model of TV series to release updates is an opportunity to engage users and build closer relationships.