Drone-Ver v.1.sleepy.0.0.calamitous.1437363538.7


Given a version number MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN, manage your releases as laid out in this comic :

  1. MAJOR is incremented when you feel like you've added something cool.
  2. MOOD is how you felt when you released this version.
  3. ISSUES is the number of open GitHub issues against your project.
  4. SOCIAL is the number of GitHub forks & favourites of your project.
  5. DICTIONARY is a random dictionary word.
  6. UNIXTIME is the unix time, and
  7. SEVEN is always the number seven (7).


In the world of software management, there exists a dread place called "San Francisco." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If you don't want to end up in San Francisco with the rest of the developers - or worse, in Silicon Valley - you're going to have to do everything that you can to make versioning even harder.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are mostly based on what I thought would be most entertaining at the time that I first came up with Drone-ver. For this system to work, you need grim-eyed determination and a madness that seeps out of every pore in your being, affecting both your work and your relationship with others. It is probably best if you not work on a Drone-ver project with other developers, as your respective moods might become horribly entangled.

Once you've decided to use Drone-ver, you mostly communicate changes to your project using Twitter. If people using your library don't catch the update, you will post it again, but later in the day. Do your best to discourage these people. They are trying to steal your libraries to use in their own code. You owe them nothing and honestly wonder if they are stealing your butter knives when you are not watching your utensil drawer.

I call this system "Drone Versioning". Under this scheme, version numbers convey almost no useful information whatsoever.

Drone Versioning Specification (Drone-Ver)


  1. Software using Drone Versioning MUST be AWESOME TO THE POWER OF COOL.
  2. Why are we SHOUTING?
  3. A normal verion number must take the form MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN. If it takes another form, please call an EXORCIST immediately. You are in DANGER.
  4. I don't know what we're YELLING ABOUT.
  5. Major version zero (0) is for initial development. Anything may change at any time. This is also true of life. Take a moment to PONDER this, perhaps over a whisky, while staring out a window.
  6. Build metadata MAY be denoted by appending a plus sign, followed by a short paragraph describing your summer at camp. Your summer at camp SHOULD HAVE been MAGICAL.
  7. Precedence refers to how versions are compared to each other when ordered. When making precedence calculations, ALWAYS discard everything except for the Unix time and sort by THAT. It is NOT RECOMMENDED that you use the random dictionary word instead, but it would probably be MORE EXCITING.
  8. ALWAYS I wanna be with you and make believe with you.

Why Use Drone Versioning?

This is not a new or revolutionary idea. Not even a little bit. In fact, you probably do something close to this already, because you read the SemVer specification and you were like "urgh, standards. Not for me!".

The problem is that "your standard" isn't good enough. Without compliance to some sort of formal specification, your version numbers will never truly be spectacularicento, a word I made up that is a portmanteau of magnificent, spectacular, and the letter 'O'. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, your users will leave you to your coding in peace, never again e-mailing you at 7AM on a Saturday.

QIIPAM (Questions I Imagined People Asking Me)

This is terrible.

That is really more of a comment than a question.

I hear TenVer is good. Why shouldn't I use that?

TenVer is a different standard for versioning that is incompatible with Drone-Ver and therefore sorely lacking.

What about SemVer? Isn't that a practical, no-nonsense standard?

SemVer? Never heard of it.

Doesn't this discourage rapid development and fast iteration?

You're damn right. Go forth and turn pip into a wasteland.

You can leave npm out if this, it is already a wasteland.

How do I know when to release 1.0.0?

This is an invalid Drone-ver. Why would you even ask me that?

Is it "Drone-Ver" or "Drone-ver"? You seem to use both interchangeably.

I can tell that you are a software developer.

What about "Dronever"?

No. Emphatic no. Do I look like I have the money to register two domains?

What do I do if I accidentally release a backwards incompatible change?

Rejoice. To embrace Drone-Ver is to embrace chaos itself.

How should I handle deprecating functionality?

With gusto.


The Drone-Ver specification was authored by Curtis Lassam, internet cartoonist and internet gadabout.

If you'd like to leave feedback, I'm sure you'll find a way.


This document is a remix of SemVer. Except this standard is way better. Especially better than TenVer, which was authored by a real scoundrel.


Creative Commons No-Commercial Closed-Captioned International Share-Alike