Spec-tacular - SemVer & Beyond

Rate this content
Bookmark

This talk unravels the intricacies of Semantic Versioning (SemVer) while delving into the real-world, practical complexities of navigating dependency hell. Gain new insights into the origin of & challenges with versioning, discover the hidden powers of the existing semantic version schema, and catch a glimpse of the future of package management. Whether you're a seasoned developer who lives & breathes conventional commits or a newcomer eager to understand this essential aspect of our package ecosystem, this talk promises to level up your understanding of everything spec.

This talk has been presented at DevOps.js Conf 2024, check out the latest edition of this JavaScript Conference.

FAQ

Semantic versioning, also known as SEMBR, is a versioning schema widely used in software development to manage versions of software packages. It helps in avoiding 'dependency hell' by specifying rules that govern how version numbers are assigned and incremented.

Rich Hickey's main criticisms of semantic versioning include the belief that it is a bad specification with too much room for improvement, the idea that software should never release breaking changes, and the acceptance of software stagnation as a consequence of avoiding these changes.

Darcy Clark mentioned a new JavaScript package registry and client called Volt, which he founded. More information about Volt can be found on its website, VLT.SH.

The current implementation of semantic versioning in the JavaScript ecosystem includes additional grammars and capabilities such as sets, ranges, and comparators that are not part of the original semantic versioning 2.0.0 specification.

Darcy Clark proposes several changes to the semantic versioning specification, including correcting the definition of patch versions, redefining build metadata, and introducing new concepts like software context and version sets to better manage software versions.

The 'sixth circle of dependency hell', as described by Darcy Clark, refers to the heresy of inconsistent standards across packaging tools, leading to different dependency graphs depending on the tool used, which complicates dependency management.

Darcy Clark founded Volt to address limitations and challenges in existing package registries and clients by building a new JavaScript package registry that incorporates a better versioning schema and improved dependency management.

Darcy Clark believes that the creation and versioning of software should mimic real life, acknowledging that changes, including breaking ones, are natural and necessary for growth and improvement, similar to life's unpredictable changes.

Darcy Clarke
Darcy Clarke
22 min
15 Feb, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Welcome to DevOpsJS 2024! We'll be discussing semantics and versioning schemas, particularly semantic versioning (SEMVR). There are concerns about the flaws in SEMVR and the need to embrace change in software development. Dependency hell in the JavaScript ecosystem has been addressed through semantic versioning and new capabilities. However, there are still issues with the SEMBR spec, including absent definitions and problems with build metadata. To improve versioning, we need to address missing definitions and consider a new spec for the future.

1. Introduction to Semantics and Versioning

Short description:

Welcome to DevOpsJS 2024! We'll be discussing semantics and versioning schemas, particularly semantic versioning (SEMBR). I'm Darcy Clark, a software engineer with over 20 years of experience. Inspired by Rich Hickey's talk, I have some concerns about his views on Semver. Let's dive in!

Welcome, thanks for joining DevOpsJS 2024 and taking an interest in my talk today. We'll be diving into one of my favorite topics, which is semantics, and more specifically versioning schemas, the most popular of which being semantic versioning, or otherwise known as SEMBR.

First a little bit about me. My name is Darcy Clark. I've been a software engineer for over 20 years, developing both open and closed source software. Had a long career as a consultant, working with amazing brands, agencies, and large enterprises. I also co-founded a company called Themify about 10 years ago, which serves commercial WordPress themes, and it's still around today. I spent the last four years working on NPM at GitHub, the open source CLI teams, both the GitHub and NPM CLI teams. I'm building a new JavaScript package registry and client, a company I founded last year called Volt, and you can check out more if you'd like at VLT.SH.

So this talk was actually inspired by a talk by Rich Hickey. Back in 2016, he did a keynote called Speculation, in which he dives into software versioning and semantic versioning itself. If you haven't watched one of his talks before, I highly recommend going to YouTube and taking a look at some of his work. This talk specifically is amazing, and I think he's a great speaker with some awesome insights. That said, I do have a few issues with some of the key takeaways from Rich's talk, his speculation talk. As far as I can tell, no one has brought up any issues in the last seven years, so I hope I'm not alone.

2. Challenges with Semver and Embracing Change

Short description:

Rich believes Semver is flawed and only accepts backwards-compatible changes. I believe software should reflect real life, embracing mistakes and change. Stagnation and excessive permissiveness can lead to bloated interfaces. Software versioning should anticipate and communicate necessary changes.

The first of which is that Rich quite broadly believes Semver is a bad spec. I'm not completely against him here. I think there's a lot of room for improvement, and we'll definitely dive into that a bit later. The second major statement and takeaway is that we should never be releasing breaking changes, or if we need to release breaking changes, we should do that under a new name. In other words, he believes the only acceptable changes to software should be backwards-compatible ones. And, of course, lastly, he's okay with the idea of software stagnating, which is in line with that second bullet.

For me, I believe the creation and versioning of software should mimic real life. Sometimes things change, and changes aren't perfect. We break things, and that's a part of life. We shouldn't be afraid to make mistakes, and we should be compelled to create environments where it's easy to learn with minimal external impact when we get things wrong. In the case of stagnation, it's a natural phenomenon, but it's not something that we should promote or think that's positive. Software stagnation is the same. Refusing to foster and maintain software means it will likely meet a similar end as in the real world. Death, or worse, irrelevancy. When we talk about the easing of constraints or creating a larger API surface, we begin to see ourselves again in an unnatural, uncomfortable territory. Being more permissive with software means over time you will end up with a bloated public interface that you need to support. This is a self-imposed burden which can only be reflected through, which can only be rectified through breaking changes. This is similar to how we, you might need to break bad habits in the physical world. But those end up extending your lifespan.

Lastly, I find it wholly unnatural to pollute our ecosystems with spurious namespaces. Our version schemas should be there to free us of the restrictive contracts we have with historical interfaces, so long as the project's underlying purpose has not changed. This point of view I have comes from my understanding that software and software versioning is messy, just like life. Software changes over time, and this reflects how we all organically learn and grow. Software changes can break things, just like in the real world. Not all changes are expected, and sometimes they break. But we must respect and accept that breaking changes are part of life and are part of growing. Having a schema in place which anticipates that as necessary, that as a necessity, is critical to creating a thriving ecosystem of versioned software. Sometimes changes may even take things away, which is another type of break and change. But again, this reflects real life. And ultimately, a software versioning specification is meant to codify the signals for communication of change.