Given a version number MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN, manage your releases as laid out in this comic :
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.
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.
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.
That is really more of a comment than a question.
TenVer is a different standard for versioning that is incompatible with Drone-Ver and therefore sorely lacking.
SemVer? Never heard of it.
You're damn right. Go forth and turn pip into a wasteland.
You can leave npm out if this, it is already a wasteland.
This is an invalid Drone-ver. Why would you even ask me that?
I can tell that you are a software developer.
No. Emphatic no. Do I look like I have the money to register two domains?
Rejoice. To embrace Drone-Ver is to embrace chaos itself.
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
