Proposal for semver 2.0.1 (as presented) for branch patch/2.1.* for 3.*.* "cognitive toil reduction"

[elasticdotventures]

👋 I propose for future semver the community simplify the formatting. This is an early DRAFT WIP. Lots of ideas, feedback is 👍

🐭 Version 2.1.* as a proposal for a suite of idiomatic codified build actions which can detect & auto-version as a way to use semver as a way to simplify git to noobs "reduce the learning curve" aka "getting git" (to understand git)

🙏 I hope the changes herein could make semver more approachable "at a glance" & collectively streamline the entire field of version control within dev/ops & software engineering more intuit to neophytes by idiomatically & programmatically encoding information and move humanity perhaps one giant squeak forward by reducing the cognitive burden associated with using git for which sem-ver is logically intertwined with. The feature is known as "auto-tagging" using build action mechanisms are popular and used in conjunction with semantic versioning & code quality / linting checks.

I will try to explain this idea "idiomatic semantic versioning" to a broad audience I hope will review this with some background, it is one of those things where much like Rokos Basilisk, it's memetic a thought cannot be unthought. But I struggle to find the words to explain idiomatic naming because many of the reviewers may not be as fluent in English or programming paradigms & venacular that I know, as is commonly the nature with ideas not yet in the zeitgeist. Fortunately, sem-ver is enjoying widespread adoption such that sem-ver 3 is next on the path toward ubiquitous adoption.

This proposal for version 3.x.x includes the introduction of semi-intuitive "idiomatic" well-known patterns that might include (for example) MINOR Year, Week presently this is: "202224" and MAJOR GMT and a plurality of "counters" or auto-tagging such as JulianDay, Hour Minute Second for PATCH.

⚠️: If you don't already understand MAJOR, MINOR, PATCH versions - then don't read this (this won't make sense). Note: this might not make sense even if you do understand those. I will do my best. To introduce several ideas. 🤪

To briefly resummarize the big sem-ver 2.x ideas NOT significantly affected in this proposal

MAJOR version - this is ultimately a proposal for semver 3.. - focus on the major 'build breaking, auto-regression failing' numbers going forward (i.e. when a regression test fails, a breaking change has occurred, then a major version bump occurs).
But is a request for experimentation & community discussion as to what might sem-ver version 3 might or could include. So please upvote and comment and I am happy & capable to write the code & examples to implement after review.

My Proposed Goal for sem-ver 3 'idiomatic'

Most of the time everybody (both devs & ops & the org) should mostly-only care about the breaking changes, the MINOR is important for functionality levels (with polyfill, backward compatibility) and PATCH are noise/counters. The build # number could be 1,2,3 it could be 100,200,300 (but it should maintain forward padding digits i.e. starting at 001 so it sorts nicely, as a DAMMIT optimization) and this itself is a signal of the "PATCH CADENCE" (i.e. how many patches before an auto MINOR). and usually this should be set at 10x whatever the high watermark of the prior MINOR EPOCH was. I.e. if a PATCH version can reach 10 patches in an EPOCH then the new high watermark is 000 so that at least it overflows nicely.

The PATCH digits can/could be like windows in the tens of thousands (presently, at time of writing *MY Windows 11` uses semver 2 and my system-os says Version 10.0.22621 Build 22621) despite my OS identifying as "Windows 11" (🤦‍♂️) .. which is certainly anti-idiomatic (i'll say "idiotic" as a concise way to explain anti-idiomatic, itself is a double negative of the word "idio", greek meaning own, personal, distinct). Anti-idiomatic patterns seem idiotic to me as a person who likes things to make sense DAMMIT (*this is an acronym explained below, i swear I'm not swearing 🤪).

For example Windows 11 should be major version 11, not version 10 - and so in this case I'm specifically calling out Microsoft as a candidate who would benefit from this sem-ver 3.. to increase idiomatic ability to grok git & versioning intuitive).

I also respect forward thinking languages like Javascript/Typescript & RUST (that I know of) provide forward polyfill so the need for implementing a breaking change can be all but obliviated and in this case a major version (with languages of such regression control) should continue to use MAJOR version numbers to codify and represent new operational patterns or one or more usability or internal capability boundary transitions in how the system or software package operates. This is fine.

Limiting the Crater Size: Why patch/2.1.* becomes v3..

This proposes both increasing sem-ver complexity and introducing specific measures to reduce that cognitive toil. To say major versions on a version-repository, in software - we would say major versions are Build breaking, regression test failing refers to a process known as code-checking & Linting which is part of a suite of automatic source code validation systems used in modern software delivery pipelines. This proposal proposes having an open Branch patch/2.1.* proposes linting rules which would be guaranteed (by semver community contract, after a period of community review, say 1 year or more) to be forward compatible or add idiomatic behaviors found in version 3.x.x - as such is "conceptually" a breaking change to semver related to how versions are expressed by using the PATCH or MINOR to indicate an idiomatic versioning pattern. Perhaps ultimately the patch/2.1.* is not accepted in version 3 and that is fine too, so this proposal is intended to limit the size of the potential impact crater and allow a more diverse set of potential version lint's & validation checkers to be added.

🤓 I have written this in an already semver 2 compatible, so the future-next-gen extension rational to re-iterate

🧠 semver "cogntive toil reduction" - my brain doesn't want to sort & process semantic versions in the present pattern.
I know I am not alone. I try to onboard organizations to advanced 'automated dev/ops' git usage - and increase the accessibility for new users joining communities planning projects in git & github. I would also like the ability to easier automate tagging with git actions. Using this approach build actions could be added in git templates to auto-version in pipelines and provide useful encoded context at a glance. This way code, containers, etc. can all use the same tagging conventions.

🎶 PATCH number is "noise" v3 --- now maybe the noise is a catchy tune, maybe the noise is static until you know how to decode the digital AM/FM signal. This proposal does not attempt to dictate the PATCH number can be a signal in version 3, but this signal could also be something as a sequential number which is auto-bumped. The MINOR version is most significant after the MAJOR number, that is the reason the PATCH is noise.

👯‍♀️ The ideas presented herein with regard to future version 3 include the idea that semver itself is a versioned implementation of Hilberts Grand Hotel Paradox and such it presents an infinitely large and complex space because each version of sem-ver has an infinitely large number of versions within it. Such that version 3 is proposed conceptually as a 'patch/2.1.*' branch in how sem-ver naming in the release 3.0.0 might be further simplified. The names and numbers are arbitrarily large.

🦬 I won't prescribe specifically how the PATCH for 3.0.* becomes a branch for anti-toil automation and idiomatic naming proposals. I do not enjoy having to explain hilberts grand hotel paradox anymore than I do explaining "how binary works" when trying to explain how I know what will happen inside a CPU register and why people should avoid filenames with spaces on unix systems. Each of those and thousands of other rules related to the idiosyncratic behavior of languages can potentially be obviated by this approach to sem-ver 3, so this benefits the technical community.

🧑‍🏫 Trying to break down complex topics to executive decision makers can be difficult, organizations resist change & adoption for fear of the unkown. Versioning is not attributed frequently as a highly technical cognitive burden every master & wizard will inevitably experience, must look up, reference in HISTORY, build-notes, git-blame blabla (my assumption is any person reading this understands that pain). Thus as idioms can be added, to make them more approachable, by adding monadic functors to encapsulate ideas - sometimes benefits requires hiding the complexity (of git, semver) inside a box that allows a new person to "get git" quickly and with the lowest cognitive burden as to make it the most potentially accessible. This is no different than an elementary algebra book only giving students examples of equations that factor easily into round numbers before approaching more complexity. Semver is an "elementary" introduction to version control on git, and as such it must be placed very early in the learning sequence (and it is CERTAINLY better than hashes! and explaining signatures which is a much more advanced concept)

🐙 SO we have established, Git is itself is a versioning tool, github.com is a site, and a person must quickly understand "get" the semver format before they can understand git. I.e. semver is now a prerequisite to fully learning & understanding git - which itself is a cognitive burden with specific expertise-domain vernacular (branch, commit, pull, etc.) that has no intuitive relation to semver. But I will assume for the sake of rationality that the person reading this will already understand the basics of git, automation & dev/ops and can appreciate that part of mastering a subject is teaching it to somebody else. Remember, that every person in a intro to coding, python, rust, any language or machine learning, even zero code might be learning git on some level - git is a ubiquitous tool.

(This is a pattern/excerpt from my upcoming memoir entitled "don't a make me/i think" DAMMIT, a nooblets introduction to building anti-Toil & Advanced Automated Yak Shavers)

🤔 The case of & for idiomatic anti-toil conventions for students:

• the only dumb question is the one you or i didn't ask (the part of the explanation not understood)
• answering overly complex questions repeatedly is a form of inhumane cognitive torture
• the only best answer is idiomatically intuitive to the question, you or i didn't need to ask because it was understood.
• human wet-ware benefits for simplified thinking as complexity in a domain grows so must it's categorization to encapsulate that complexity (many smaller ideas into one bigger idea) and this is true in many engineering fields from mathematics, physics, chemistry, etc. each have their own venacular and semver is undoutably one of the ideas which covers the entire expanse of software.

MAJOR = breaking version (bumped by author or automatically on failure of regression)

These examples are done with unix date command, to explan how idiomatic formatting beginning in version 3 might be implemented.

4 digit 3.0.0 proposed 'simplified' format in branch/2.1.* as proposal/format 3.4.0 (must have a 4 digit MINOR, 6 digit PATCH)

• 🤓 concatenate two year/month, 4 digit MINOR with intra-epoch internal counter
• MINOR=date +'%y%g'
• PATCH=intra-epoch-count.sh

alternative MINOR 3.6.9 digit format

• Equally acceptable version 9 is a six digit format

• MINOR=date +'%G%V'
• PATCH=date +'%j%H%M%S'

• Conceptually these are the same, the 6.9 format is proposed as the longest with one release every second. (3 digit day of year, two digit hour, two digit minute, two digit second)
• Suddenly knowing these patterns tells a story! .. its IDIOMATIC!

Timezone Considerations

• the examples above are over-simplified, in practice & production, please make sure to set the TZ.

• MINOR=date +'%G%V' --date='TZ="Etc/GMT"'

🧙‍♂️ The case for "v3.0.x" major semver adoption (extreme forward thinking)

🔮 Semver 3.0.x format, and simultaneously publishing versions 3.x.x as a major version "for format" each having an alternative PATCH format within the version 3 series to be about "idiomacy", to be idiomatic ("easily understood") and making version 3.x.x about proposals for tagging that can be referenced and having these versions & build actions coalesce over a calendar year. with zero being infinite length unvalidated and version 3.0.0 being the last version that does not include idiomatic formatting unlesss this is ultimately broken by version 4.x.x (and then a case for regression is provided below)

👀 The idiomatic regression hack - pre 3.x

And that proposals for future related to PATCH hacking in future Semvers include historical context, i.e. branching on semver 2.1.x intermediate (pre- 3.x) include a specification for date linting rules. These can be incorporated into tools like cargo which have git capabilities in them and later perhaps there is sem-ver format, but hopefully the linting rules for sem-ver recognize that according to hilberts paradox this isn't actually an issue. sem-ver can always invent new numbers to hack its way out of the scenario using the conventions described herein.

Using build actions to automatically tag in this semver repo.

😇 While I do not wish to offend anybody with more number patterns, I hope this makes sense to others - i.e. once you see the MINOR version, it's instantly "better", and the PATCH version or approach might give some context to it's anticipated cadence and organizations can find the MINOR version which suits them and might even represent an EPOCH counter within a YEAR/WK (but for organizations which have a greater EPOCH cadence than a week, say monthly or weekly or aligned by an organizational calendar by aligning these to FORTNIGHTLY "only even releases YEARWK" or QUADWEEKLY "only releases divisible/modulo by 4" .. which is similar but not same-same to MONTHLY but fits better into most organizational calendars since 365.25 doesn't divide evenly and since covid WFH has broken the concept of "in the office" generally) but there are a plurality of ways to idiomatically streamline versions in ways that will be easier to learn the current approach in version 2 and the goal of branch "patch/2.1." is to address these ideas for companise planning to adopt sem-ver 3.x.x with version 3.0.0 being last 2.x.x non-linted compatible version. and version patch/2.1. having the goal of adding idiomatic improvements summarized herein.

🌿 Further most organizations use a branch naming version which is more intuitive & encodes a bit of project identity, common rallying word. Ubuntu is one example that uses Development Codenames to simplify versioning
https://wiki.ubuntu.com/DevelopmentCodeNames which happens because human brains don't like to remember arbitrary numbers.

🤖 I believe this particular approach for SEMVER would be especially useful to people new to git "noobs" - in the machine learning & Artificial intelligence field and those languages which synchronize their build/releases to a calendar since it has date & time encoded as such a new person (such as a person studying fundamentals of a framework) can adopt a semver for both models and frameworks, as well as the geometry as code & robotics design community who tend to only forward version, where GIT is now used as an underlying source of truth in web3 communities such as linux foundation, cnsf, notion, filecoin, etc. and many times those organizations will be hiring not-developers to use git in various roles. Most of these orgs have had significant "DAMMIT" complaints related to git's usability "learning burden".

📆 semver v1, v2 is undoutably useful in release tagging - with the proposed changes, tags could be used as build actions in default git templates, etc. to obscure more complex topics such as hashes for "noobs" & build-actions. (At the same time presenting the concept of hash later, as a digital signature, where it has more relevance)

🤓 GIT and versioning presents as something an entry level person -- i.e. every very amateur student who might be a future dev must understand very early in the git learning curve, regardless of their discipline. (NOT ALL PEOPLE USING GIT THESE DAYS ARE SOFTWARE DEVELOPERS)

💡 The goal is to provide useful context "at a glance" on the age in the version - such that organizations & adopters can easily provide patterns for assessing the relative "age" & "stability" of their systems if widespread adoption was to occur, including someday non-compliant "minimum" sem-ver in tools such as cargo, podman containers, etc. where there are multiple version numbers and they should closely align (or adopt) the same tagging style from their git container. (This allows versions to be tagged by sem-date rather than arbitrary hash, which must be then referenced by date). Roadmaps can now be planned and communicated by YEARWK for example which is perhaps more suitable to a SPRINT/SCRUM and coordinated vacation planning, etc.

Examples of Future Zodiac Signs/PATCH version 3.0.12

I propose, somewhat humourously the idea of using a SEMVER 3.0.2 patch as an idiomatic release, & naming convention being zodiac
♈: Aries Dates: March 21-April 19.
♉: Taurus Dates: April 20-May 20.
♊︎: Gemini Dates: May 21-June 20.
♋: Cancer Dates: June 21-July 22.
♌: Leo Dates: July 23-August 22.
♍: Virgo Dates: August 23-September 22.
♎: Libra Dates: September 23-October 22.
♏: Scorpio Dates: October 23-November 21.
... etc. (which there are 12 per year)

and organizationally organizations might target specific types of releases for specific periods in such a naming convention (in terms of astrologically speaking, what is dictated to have the best success). These naming conventions while silly, the memetic approach will still roughly align with the week/month to be compatible but not identical but also allow a symbolic representation and present naming convention.

Future Proofing using Hilbert & Even/Odd Numbers >3

Perhaps I'm being overly ambitious and this is better suited as a version 3.. but what I'm proposing would be a "forever" version & branch "patch/2.1." for a type of change and "rational symbolic meaning" (called an idiom) - an examples of idiom(s) that could be broadly kept & tracked within this version and assuming future versions after 4 will/could have the luxury of changing things again, but hopefully these proposals might be mandatory in version 3.0. would likely take more than a decade to enjoy any substantial adoption, but as a proposal for how version 2.1.* might be reserved for proposals of a specific type as mentioned below and for people who thing this is a dumb idea, I would only suggest reserving mod%2=0 for this pattern going forward i.e. all versions after 3, if a version 4 is published, then version 5 is automatically considered to be 4|3 (binary or | as opposed to pipe), and if there is a semver 6, then 3|7 is inclusively the same patches & linting (future proofing) as a contract. I realize this will probably take decades, I just want to be clear that I'm trying to be inclusive and non breaking, and only even versions of semver below version 3 are expected to have linting, auto-tagging & idiomatic simplifications.