A place to cache linked articles (think custom and personal wayback machine)
Du kan inte välja fler än 25 ämnen Ämnen måste starta med en bokstav eller siffra, kan innehålla bindestreck ('-') och vara max 35 tecken långa.

index.md 6.1KB

9 månader sedan
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189
  1. title: YOLO Ver
  2. url: https://yolover.org/
  3. hash_url: 959374400b4bb6d58c74116ffd08281b
  4. archive_date: 2024-02-09
  5. og_image: https://yolover.org/card.png
  6. description: Realistic versioning for modern software.
  7. favicon: https://yolover.org/favicon.png
  8. language: en_US
  9. <h2>Summary</h2>
  10. <p>
  11. Given a version number MAJOR.MINOR.PATCH, increment the:
  12. </p><ol>
  13. <li>
  14. <strong>Major</strong> version whenever you feel like it.
  15. </li>
  16. <li>
  17. <strong>Minor</strong> version whenever you feel like it.
  18. </li>
  19. <li>
  20. <strong>Patch</strong> version whenever you feel like it.
  21. </li>
  22. </ol>
  23. <p>
  24. Additional labels for whatever you feel like are available as extensions to
  25. the MAJOR.MINOR.PATCH format. The more the merrier.
  26. </p>
  27. <h2>Introduction</h2>
  28. <p> For years the software industry has used systems like
  29. <a href="https://semver.org"><strong>semver</strong></a> and <a href="https://calver.org"><strong>calver</strong></a> to communicate with users
  30. what to expect in an update. The prescriptiveness of <strong>semver</strong>
  31. granting relief to the library user who only has to update from version 1.1.0
  32. to 1.1.1 to make most recent Snyk alert go away. The flexibility of
  33. <strong>calver</strong> allowing the busy application developer to release
  34. without fear, not needing to worry about whether a set of changes is
  35. significant enough to justify a 2.0.0 release and the awkward conversation
  36. with marketing that will ensue.
  37. </p>
  38. <p>
  39. But behind their promises, these systems are flawed. They do not
  40. represent the reality of modern software practice. This document aims to
  41. rectify that. It is a call to arms for the software community to embrace
  42. how people really version their software:
  43. <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
  44. Ver</strong>.
  45. </p>
  46. <h2>Goals</h2>
  47. <p>
  48. The goals of <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
  49. Ver</strong> are simple: to allow you to justify any version bump you
  50. want. You've changed stuff, who knows exactly what, and figuring out whether
  51. it's technically a major, minor, or patch change is too much work. All
  52. you really want to do is paste "bug fixes and performance improvements" into
  53. 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>
  54. Ver</strong> is here to help.
  55. </p>
  56. <p>
  57. What follows are example conversations you might have with users that
  58. 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>
  59. Ver</strong>:
  60. </p>
  61. <h3>Example 1</h3>
  62. <ul>
  63. <li>
  64. <strong>User</strong>: The most recent patch-level release of your
  65. software broke our service in production. You shouldn't have done that.
  66. You should instead consider <strong>semver</strong> so your users know
  67. what to expect.
  68. </li>
  69. <li>
  70. <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>
  71. Ver</strong>.
  72. </li>
  73. </ul>
  74. <h3>Example 2</h3>
  75. <ul>
  76. <li>
  77. <strong>User</strong>: The most recent major-level release of your
  78. software was a huge disappointment. Almost nothing changed. Why
  79. would you bump the major version for no reason?
  80. </li>
  81. <li>
  82. <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>
  83. Ver</strong>.
  84. </li>
  85. </ul>
  86. <h3>Example 3</h3>
  87. <ul>
  88. <li>
  89. <strong>User</strong>: I can't figure out what the version number of your
  90. software means. Can you explain all of the parts? e.g. "Version
  91. 121.0.6167.139 (Official Build) (arm64)"
  92. </li>
  93. <li>
  94. <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>
  95. Ver</strong>.
  96. </li>
  97. </ul>
  98. <h2>Specification</h2>
  99. <ol>
  100. <li>
  101. </li>
  102. </ol>
  103. <h2>Recommendations</h2>
  104. <p>
  105. While <strong><span class="y">Y</span><span class="o">O</span><span class="l">L</span><span class="o2">O</span>
  106. Ver</strong> does not require any specific versioning scheme, we can
  107. recommend some best practices from industry to get you started.
  108. </p>
  109. <ol>
  110. <li>
  111. Never, <strong>ever</strong>, release a version 1.0.0. This ensures
  112. compatibility with <strong>semver</strong>.
  113. </li>
  114. <li>
  115. Ensure that some artefact if your build process makes it in to your
  116. version. This could be a build number, a git hash, or a timestamp. This
  117. introduces visual noise and makes it more difficult to know what's
  118. changed.
  119. </li>
  120. <li>
  121. If you have a direct competitor, ensure that your version numbers are
  122. higher than theirs. This will make you look more successful.
  123. </li>
  124. <li>
  125. Consider releasing a breaking change without modifying the version number
  126. at all. This will keep your users on their toes.
  127. </li>
  128. <li>
  129. Every once in a while, skip a number. People love mystery.
  130. </li>
  131. <li>
  132. If your software depends on other software, consider not specifying a
  133. version of those dependencies. This ensures all of your users get a unique
  134. experience.
  135. </li>
  136. </ol>
  137. <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>
  138. Ver</strong> versions</h2>
  139. <pre>
  140. &amp;ltvalid-yolover&amp;gt ::= &amp;ltany-char&amp;gt &amp;ltvalid-yolover&amp;gt | &amp;ltany-char&amp;gt
  141. &lt;any-char&gt; ::= &lt;letter&gt; | &lt;digit&gt; | &lt;punctuation&gt; | &lt;symbol&gt; | &lt;whitespace&gt; |
  142. &lt;emoji&gt;
  143. &lt;letter&gt; ::= "a" | "b" | "c" | ... | "Z"
  144. &lt;digit&gt; ::= "0" | "1" | ... | "9"
  145. &lt;punctuation&gt; ::= "." | "," | ";" | ":" | "!" | "?" | "-" | "_" | ...
  146. &lt;symbol&gt; ::= "@" | "#" | "$" | "%" | "&amp;" | "*" | "(" | ")" | ...
  147. &lt;whitespace&gt; ::= " " | "\t" | "\n" | "\r"
  148. &lt;emoji&gt; ::= &lt;standard-emojis&gt; | &lt;extended-emojis&gt;
  149. &lt;standard-emojis&gt; ::= "😀" | "😂" | ... | &lt;any other standard emoji&gt;
  150. &lt;extended-emojis&gt; ::= "👨‍👨‍👧‍👦" | "🏳️‍🌈" | ... | &lt;any other extended or combined emoji&gt;
  151. </pre>
  152. <h2>License</h2>
  153. <p>
  154. <a href="http://www.wtfpl.net/">WTFPL</a>
  155. </p>
  156. <h2>Attribution</h2>
  157. <p>
  158. This document is a parody of <a href="https://semver.org/">semver</a> and
  159. <a href="https://calver.org/">calver</a>. It is not intended to be taken
  160. seriously.
  161. </p>