title: YOLO Ver url: https://yolover.org/ hash_url: 959374400b4bb6d58c74116ffd08281b archive_date: 2024-02-09 og_image: https://yolover.org/card.png description: Realistic versioning for modern software. favicon: https://yolover.org/favicon.png language: en_US

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

Example 2

Example 3

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

&ltvalid-yolover&gt ::= &ltany-char&gt &ltvalid-yolover&gt | &ltany-char&gt
<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.