A place to cache linked articles (think custom and personal wayback machine)
您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

9 个月前
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>