On The Road To Professional Web Development | Semantic Versioning

*The objective of this article is to prepare for a technical interview. To succeed (1) we must be technically proficient, and (2) we must be capable of communicating our proficiency effectively.

In this post, we’ll first become conversationally fluent on the topic. Next we’ll read the official specification to ensure we understand the nuances of semantic versioning. Finally we’ll finish the discussion with a curated list of (reportedly) common interview questions.

This post is part of a series on becoming a professional web developer — click here to navigate to the table of contents*

Part I: Semantic Versioning

How Difficult Is It To Master?

While many software versioning schemes exist, the software versioning approach known as semantic versioning (or SemVer) is a single technique, completely defined in a written specification. It is only a few pages long. Understanding the SemVer specification is equivalent to understand semantic versioning. So relax and enjoy this post — the road to professional web development isn’t always this easy.

Semantic Versioning: What Is It?

If we used version numbers for our files intelligently, they could be extremely valuable. The problem is that our efforts are useless unless we’re consistent about it. This is where semantic versioning comes in. It specifies an extremely clear system for numbering our projects.

It has the basic form semver ::= Major.Minor.Patch, where major, minor, and patch are non-negative integers. There is more to this story, which we’ll learn shortly.

What Is Semantic Versioning To Developers?

• SemVer.org is a website maintained by this GitHub repository. It tells us everything there is to know about semantic versioning
• The SemVer specification was authored by Tom Preston-Werner, one of the co-founders of GitHub. (I discuss his team’s success story in a previous post about GitHub)
• Semantic versioning isn’t necessarily about making the developer’s life as easy as possible — it’s about being professional and doing the job right. At some point in our careers, others may develop code that relies on ours as a dependency. If ours changes, all their hard work might break. With semantic versioning, we make iterations of our code available in a consistent way to avoid this category of issues.

What Terminology Comes Up When Discussing Semantic Versioning?

• Backus-Naur form (a.k.a. Backus normal form, BNF): a notation technique. “SemVer.org has a section that explains semantic versioning using BNF instead of plain English. The information conveyed is equivalent to the plain-English description”
• Build metadata: sometimes software builds require the same software with different metadata. “the SemVer specification allows build metadata to be stored in a semantic version name without breaking convention (build metadata is prefixed with a +)”
• Dependency hell: the sum total of challenges associated with version lock and/or version promiscuity. “Semantic versioning mitigates the risk of dependency hell”
• Dependency specifications: versions from a semantically-versioned project can be referenced as stable dependencies for other projects. “These can be single versions or version ranges”
• Deprecating functionality: functionality to be removed in future versions. “SemVer.org recommends an approach to function deprecation”
• Major version: feature additions or modifications that impact backwards compatibility. “Major versions are the X in semantic version X.y.z”
• Minor version: feature additions or deprecations that do not impact backwards compatibility. “Minor versions are the Y in semantic version x.Y.z”
• Offending version: versions released that unintentionally break semantic versioning guidelines. “SemVer.org offers guidance on handling offending versions”
• Patch version (a.k.a. micro version): bug fixes that do not impact backwards compatibility. “Patch versions are the Z in semantic version x.y.Z”
• Pre-release version: sometimes versions in active development need tracked without releasing the version for public use, and without incrementing the major, minor, or patch numbers. “the SemVer specification allows pre-release versions to be stored in a semantic version name without breaking convention (pre-release versions are prefixed with a -)”
• Precedence: the ‘order’ of semantic versions. “SemVer.org clearly specifies the order of version names”
• Public API: a tool that clearly specifies your semantic versioning strategy and makes versions reliably available to others. “Creating a public API is a requirement of semantic versioning”
• Regular Expression (RegEx): a string used to search other strings for patterns. “SemVer.org offers regular expressions to parse semantic versions”
• Semantic version (a.k.a. SemVer): a well known software versioning schema where version numbers have well-defined meaning. “SemVer.org maintains the official semantic versioning specification”
• Stable Release: versions of the project intended for public use via the project’s API. “Stable releases are versioned as x.y.z”
• Version lock: the inability to upgrade a package without having to release new versions of every dependent package. “Semantic versioning limits the risk of version lock”
• Version promiscuity: assuming compatibility with more future versions than is reasonable. “to avoid version lock, some projects automatically build using rules for version ranges.For example, one might be instructed to ‘build with the latest version of this package’, at which point the build tool goes to the internet, finds the latest version of that package, uses it for the build. Over time, dependencies evolve to the point that software depending on them also breaks. Semantic versioning resolves these types of issues if an automatic build tool knows to seek the latest minor version (not the latest version over all), which takes backwards compatibility into account”
• Versioned package: a version of a project with or without pre-release or build metadata. “once versioned, package versions should never be changed for any reason (including unintentional errors)”

Part II: Using Semantic Versioning

Part II focuses on using semantic versioning. Luckily for us, it’s extremely straightforward! We’ll read the manual in preparation to answer interview questions.

• All we need to do is read the Semantic Versioning specification on SemVer.org. It’s short and easy to understand — this is really all there is to it!

Part III: Semantic Versioning Interview Questions

The goal of Part III is to summarize interview questions from across on the web. Questions have been paraphrased to avoid duplicate entries. Drill on these while practicing for the interview, and don’t hesitate to Google solutions.

• compare version lock to version promiscuity
• discuss bug fixes
• discuss build metadata
• discuss deprecation
• discuss feature additions
• discuss impact of dependency updates on semantic versions
• discuss major versions
• discuss minor versions
• discuss patch versions
• discuss pre-release versions
• discuss precedence
• discuss public API
• discuss public API documentation
• discuss release 0.1.0
• discuss release 1.0.0
• discuss release versions
• list examples of valid semantic versions
• list examples of versions that are not valid semantic versions

Closing Thoughts

I hope you’ve enjoyed this post as much as I enjoyed writing it. If you have thoughts you’d like to share, your editorial suggestions are always welcome. This post is part of a series on becoming a professional web developer. If you’d like to see more content like this, please click here to navigate to the table of contents.