|
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189 |
- 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
-
- <h2>Summary</h2>
-
- <p>
- Given a version number MAJOR.MINOR.PATCH, increment the:
-
- </p><ol>
- <li>
- <strong>Major</strong> version whenever you feel like it.
- </li>
- <li>
- <strong>Minor</strong> version whenever you feel like it.
- </li>
- <li>
- <strong>Patch</strong> version whenever you feel like it.
- </li>
- </ol>
-
- <p>
- Additional labels for whatever you feel like are available as extensions to
- the MAJOR.MINOR.PATCH format. The more the merrier.
- </p>
-
- <h2>Introduction</h2>
-
- <p> For years the software industry has used systems like
- <a href="https://semver.org"><strong>semver</strong></a> and <a href="https://calver.org"><strong>calver</strong></a> to communicate with users
- what to expect in an update. The prescriptiveness of <strong>semver</strong>
- 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
- <strong>calver</strong> 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.
- </p>
-
- <p>
- 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:
- <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong>.
- </p>
-
- <h2>Goals</h2>
-
- <p>
- The goals of <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong> 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. <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong> is here to help.
- </p>
-
- <p>
- What follows are example conversations you might have with users that
- are not familiar with <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong>:
- </p>
-
- <h3>Example 1</h3>
-
- <ul>
- <li>
- <strong>User</strong>: The most recent patch-level release of your
- software broke our service in production. You shouldn't have done that.
- You should instead consider <strong>semver</strong> so your users know
- what to expect.
- </li>
- <li>
- <strong>You</strong>: lol, we use <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong>.
- </li>
- </ul>
-
- <h3>Example 2</h3>
-
- <ul>
- <li>
- <strong>User</strong>: 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?
- </li>
- <li>
- <strong>You</strong>: lol, we use <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong>.
- </li>
- </ul>
-
- <h3>Example 3</h3>
-
- <ul>
- <li>
- <strong>User</strong>: 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)"
- </li>
- <li>
- <strong>You</strong>: lol, we use <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong>.
- </li>
- </ul>
-
- <h2>Specification</h2>
-
- <ol>
- <li>
-
- </li>
- </ol>
-
- <h2>Recommendations</h2>
-
- <p>
- While <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong> does not require any specific versioning scheme, we can
- recommend some best practices from industry to get you started.
- </p>
-
- <ol>
- <li>
- Never, <strong>ever</strong>, release a version 1.0.0. This ensures
- compatibility with <strong>semver</strong>.
- </li>
- <li>
- 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.
- </li>
- <li>
- If you have a direct competitor, ensure that your version numbers are
- higher than theirs. This will make you look more successful.
- </li>
- <li>
- Consider releasing a breaking change without modifying the version number
- at all. This will keep your users on their toes.
- </li>
- <li>
- Every once in a while, skip a number. People love mystery.
- </li>
- <li>
- 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.
- </li>
- </ol>
-
- <h2>Backus-Naur Form Grammar for valid <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
- Ver</strong> versions</h2>
-
- <pre>
- &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>
- </pre>
-
- <h2>License</h2>
-
- <p>
- <a href="http://www.wtfpl.net/">WTFPL</a>
- </p>
-
- <h2>Attribution</h2>
-
- <p>
- This document is a parody of <a href="https://semver.org/">semver</a> and
- <a href="https://calver.org/">calver</a>. It is not intended to be taken
- seriously.
- </p>
|