Drone-Ver Versioning Specification


#1

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

Summary

Drone-Ver is an alternative to SemVer

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).

Introduction

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)

The key words “MUST”, “MAST”, “MIGGITY-MIGGITY-MIGGITY-MACK”, “AWESOME TO THE POWER OF COOL”, “ALWAYS”, “GROOVITATIONAL PULL”, “REQUISITE”, “SHALL”, “SHANDY”, “EQUINE”, “SCATTERBRAINED”, “NOT RECOMMENDED”, “PLEASE STOP”, and “WHY ARE YOU DOING THIS TO US” in this document are to be interpreted as described in RFC 2119.

  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.

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.

About

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

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

Attribution

This document is a remix of SemVer. Except this standard is way better.

License

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

Extra Extra

This content was originally hosted at drone-ver.org but the author decided to stop spending so much money on hilarious joke domain names.


#2

Gilmore Or Less

Of course, someone has provided a functional implementation of Drone Versioning, because the internet is an endlessly cool place.


#3

TenVer v. 10

Summary

The version of your product is and always will be 10.

Introduction

As you manage a software product, you will have many choices of how to manage its versions. Most versioning systems have the following problems:

  • Increasing complexity over time
  • Dependent on manual human intervention
  • Non-deterministic rules

As your product evolves, you will bottleneck on human-to-human communication and waste time with “version bump” code changes just for the sake of versioning your code.

Once we’ve implemented versioning, we can’t get rid of versioning, as it provides a valuable tool for people to understand the compatibility of your code.

As a solution to this problem, I propose TenVer to solve these problems. Developers will initially benefit from saving valuable time to automation of version numbers. As the product evolves, it will be easier for people to contribute due to the removal of conversation for version increments. While popular systems like Semantic Versioning or Drone Versioning can create complex versions like “1.0.0-alpha+001, 1.0.0+20130313144700”, or 3.gassy.10.3.mayonnaise.1437361913.7", Ten Versioning will convey the same information for the same code with a double-digit integer.

Ten Versioning Specification (TenVer)

The key words “MUST”, “MUST NOT”, “MOIST”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHANT”, “SHOULD”, “SHOULD NOT”, “SHOULDN’T’ST”, “SHOULD NEVER EVER”, “MIGHT”, “MIGHTY”, “UNRECOMMENDED”, “PROBABLY SHOULDN’T BUT GO NUTS”, “PROBABLY WON’T”, “RECOMMENDED”, “MAY”, “JUNE”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

A normal version number MUST take the form 10.
Version 10 SHOULD be backward compatible with versions before 10.
Version 10 MUST be future compatible with versions after 10.

FAQ

How do I know when to release 10?

You already have.

How do I version pin for compatibility?

Simply pin to version 10. This will never be a problem if TenVer is adhered to.

How should I handle deprecating functionality?

Use a different code repository.

Who else uses TenVer?

  • Microsoft - Windows 10
  • Apple - OSX
  • Google - Google X team projects

About

The TenVer specification is authored by Justin Scott, non-inventor of Gravatars and all-around cool guy.

The TenVer specification was edited by Cube Drone, internet cartoonist and author of a far inferior versioning scheme.

If you’d like to leave feedback, please open an issue on GitHub.

Not with us. Just open an issue. We’ll probably find it.