YOLO Ver

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

1. Major version whenever you feel like it.
2. Minor version whenever you feel like it.
3. Patch version whenever you feel like it.

Additional labels for whatever you feel like are available as extensions to the MAJOR.MINOR.PATCH format. The more the merrier.

Introduction

For years the software industry has used systems like semver and calver to communicate with users what to expect in an update. The prescriptiveness of semver granting relief to the library user who only has to update from version 1.1.0 to 1.1.1 to make most recent Snyk alert go away. The flexibility of calver allowing the busy application developer to release without fear, not needing to worry about whether a set of changes is significant enough to justify a 2.0.0 release and the awkward conversation with marketing that will ensue.

But behind their promises, these systems are flawed. They do not represent the reality of modern software practice. This document aims to rectify that. It is a call to arms for the software community to embrace how people really version their software: YOLO Ver.

Goals

The goals of YOLO Ver are simple: to allow you to justify any version bump you want. You've changed stuff, who knows exactly what, and figuring out whether it's technically a major, minor, or patch change is too much work. All you really want to do is paste "bug fixes and performance improvements" into the patch notes and call it a day. YOLO Ver is here to help.

What follows are example conversations you might have with users that are not familiar with YOLO Ver:

Example 1

• User: The most recent patch-level release of your software broke our service in production. You shouldn't have done that. You should instead consider semver so your users know what to expect.
• You: lol, we use YOLO Ver.

Example 2

• User: The most recent major-level release of your software was a huge disappointment. Almost nothing changed. Why would you bump the major version for no reason?
• You: lol, we use YOLO Ver.

Example 3

• User: I can't figure out what the version number of your software means. Can you explain all of the parts? e.g. "Version 121.0.6167.139 (Official Build) (arm64)"
• You: lol, we use YOLO Ver.

Specification

Recommendations

While YOLO Ver does not require any specific versioning scheme, we can recommend some best practices from industry to get you started.

1. Never, ever, release a version 1.0.0. This ensures compatibility with semver.
2. Ensure that some artefact if your build process makes it in to your version. This could be a build number, a git hash, or a timestamp. This introduces visual noise and makes it more difficult to know what's changed.
3. If you have a direct competitor, ensure that your version numbers are higher than theirs. This will make you look more successful.
4. Consider releasing a breaking change without modifying the version number at all. This will keep your users on their toes.
5. Every once in a while, skip a number. People love mystery.
6. If your software depends on other software, consider not specifying a version of those dependencies. This ensures all of your users get a unique experience.

Backus-Naur Form Grammar for valid YOLO Ver versions

    <valid-yolover> ::= <any-char> <valid-yolover> | <any-char>
    <any-char> ::= <letter> | <digit> | <punctuation> | <symbol> | <whitespace> |
    <emoji>
    <letter> ::= "a" | "b" | "c" | ... | "Z"
    <digit> ::= "0" | "1" | ... | "9"
    <punctuation> ::= "." | "," | ";" | ":" | "!" | "?" | "-" | "_" | ...
    <symbol> ::= "@" | "#" | "$" | "%" | "&" | "*" | "(" | ")" | ...
    <whitespace> ::= " " | "\t" | "\n" | "\r"
    <emoji> ::= <standard-emojis> | <extended-emojis>
    <standard-emojis> ::= "😀" | "😂" | ... | <any other standard emoji>
    <extended-emojis> ::= "👨‍👨‍👧‍👦" | "🏳️‍🌈" | ... | <any other extended or combined emoji>
  

License

WTFPL

Attribution

This document is a parody of semver and calver. It is not intended to be taken seriously.