Solecistic Versioning

solver.md

Solecistic Versioning

Some general principles:

• Guarantees (implied or otherwise) about stability will inevitably be broken, so attempting to stick to something like semantic versioning is just a lie. Acknowledge that you have no intention or ability to ensure compliance with such guidelines, and make this fact obvious (sometimes painfully so) in your versioning scheme.
• Don't use logic. Logic leads your users into the false complacency of thinking they know what's going on. Make sure that they don't.
• Use logic. Logic is what your users will attempt to use against your version numbers. Make sure their conclusions are wrong.

This document aims to widen your horizons when it comes to what a version number of name can be. The design space is much wider than either of you or me can imagine, all I can hope to do is open your eyes to the possibilities.

In consideration of these limitations, all this document will provide is guiding principles and vague ideas for future exploration.

"Solecistic" is supposed to be the antonym of semantic.

What's a version anyway?

You might think a version number is e.g. a sequence of numbers separated by U+002E, written with decimal digits U+0030 through U+0039, or something equally limited. But there are, like, 1112111 characters in Unicode and you're only going to use 11 of them?

Note that even in the world of those 11 characters, dotted-sequence version numbers have subtly different meanings - some seemingly "major.minor" versions are actually used as real numbers, with updates and patch releases adding 0.01, 0.1 or 0.5 to the version rather than step increases of minor/patch components.

Other examples:

• TeX: using increasingly precise approximations of pi written as a decimal real number.

• Windows: from major.minor to 95/98/2000 to ME/XP/Vista back to major only (but skipping 9)

• 2+3 versioning: After the success of version 1 and version 2, a big rewrite is launched to produce something New and Exciting. The resulting version 3 is a universally hated, horrible mess. After revisiting your mistake, you want to backport the good things from the failed version 3 back into the more reasonable and workable version 2. The result is 2+3 = version 5.

  Examples:

  • Winamp
  • Python, although we are still eagerly awaiting the release of Python 5

• The left shift: After releasing version 1.X you decide version numbers are increasing too slowly. Just shift out the 1 and start increasing X. Famous examples are Java 1.2 => Java 2 (now up to Java 19) and Solaris.

• The rebrand: SunOS 5.x became Solaris 2.x (retrobranding SunOS 4.x into Solaris 1.y), and starting with Solaris 2.6 left-shifted to Solaris 6.

I could go on: the point is there are so many different things you could do with your versions. Go ahead and do all of them.

Versioned evolution

Your software doesn't stay the same between versions, why should your version numbers? Switch it up and ideally only use each versioning idea once.

Or if you have to reuse an idea, make sure you don't accidentally produce a logical progression. Or if you do, make it a Red Herring.

Red herrings

Users expect version 2 to be a progression of version 1. They might also expect something like 1.1 to be an update to 1.0, even after the release of 2.0. This suggests the use of parallel stable release streams.

Exceed expectations. Release 1.1 based on version 2, release 2.1 as a patch release of 1.0.

While using many Novel Ideas and introducing as few patterns as possible between releases reduces the amount of useful information for the user (which is good), intentionally using and subverting patterns to mislead them can also be quite effective.

Ideas

A random selection of ideas to get you started:

• Mix version schemes, never use the same one twice

• Avoid order. Some schemes imply an ordering that could be mapped across schemes (e.g. i = I = 1 = A = alpha, -1 = ii = II = 2 = B = beta), don't use version "B" just after version "1".

• Common stuff: use all of numbers, letters, greek letters and names of greek letters.

• Unicode. Emojis, obscure alphabets, ꙮ's, hieroglyphics. Anything from https://en.wikipedia.org/wiki/Category:Unicode_blocks

• Unicode-versioned versioning: the number of eyes in ꙮ changed in Unicode 15.0. Use the 7-eye and 10-eye ꙮ's as separate version numbers.

• Unicode look-alikes.

  Some ASCII characters such as whitespace and punctuation can have special meanings in tools you use, making them unavailable for use as version numbers or tag names. Unicode look-alikes (such as ⡁ BRAILLE PATTERN DOTS-17) work around this by looking almost the same while getting treated as letters.

• Code names. Code names are great for obscuring ordering.

• Mixed-endian versions.

  Most schemes are "big endian" in that the most significant version comes first. Put your least significant version first. Or in the middle. For example, ACPICA uses a Ryy_zz_xx scheme for its release tags where the most significant component (the year) is the last one. Great for sorting!

• Make sure to switch endians between versions.

• Randomly add "Stable", "Unstable" and "LTS" in the version names.

• If you tag releases, don't use the same scheme as your versions. ACPICA (again) does this - versions are yyyymmdd but tags are Rmm_dd_yy.

• Natural numbers? Go further - complex, imaginary, real, rational, irrational.

• Quaternions can represent rotations in 3D space. Can your major.minor.patch version numbers do that?

• Abstract concepts and non-textual representations.

  You may run into limitations of your tools, but why not choose a particular drawing of a three-legged horse as your version number? Or the feeling of getting out of bed on a Monday morning.

  (Don't confuse the feeling itself with a text describing it though.)

About

This is the initial version of this document, you may want to use a better one.