0n-(n0n)-(maj0r)-versi0ns-

0n-(n0n)-(maj0r)-versi0ns-#N.xx

Z. Blace

... or What-a-difference-a-Version-makes ?! (to paraphrase a blues classic). This used to be obvious but it is becoming increasingly less so, especially for end-users. The text looks into version naming practices of software, and their social and cultural effects. Written from a slightly queer bias by both advocating for versions and by questioning their norms. Published as v0.4, with pending updates and hopeful of new contributions.
In times of global dominance of corporate agile software development, of cloud services and the general obfuscation of technological systems into “smart” but non-transparent technologies, software issues are being solved (or not) and features are added (or removed) on the go. With no development path or milestones overview, even software used in healthcare is almost constantly and erratically released/updated as service, based on shady managing and marketing decisions.

For many “digital native” consumers, commercial apps and services obviously change only when rebranding is done and/or all the UI/UX changes direct their focus to some (apparent) (new) (consumable) (added) ‘value’/’feature’. The update flux of smartphone software is no longer perceived as an extraordinary frequency of releases, but rather as a norm. The one-liner vague jokes by major developers in texts that describe such updates, are explicit signs of their increasing benevolence and lack of release care. So before the notion of software versions disappears even further out of sight from the desktops of users, it would be important to consider its relevance and usefulness, by considering different reception across (a)social groups and (sub)cultural effects it had or still might have.

(pre)historic context...

If you were using PCs before the 1990s, you were likely purchasing or swapping versions of software initially in an analogue form, as noisy audio tapes or sounds over dial-in BBS modem connections. Back then each new version likely brought epic joy or at least enthusiasm with a set of expectations among friends that would fill the day or a week with attention to details for all of the changes. Switching to digital media made the distribution significantly less exceptional. Floppy discs possibly still had some fragility that evoked attention and care, but with a (fake) promise of the everlasting CD medium, that got reduced to mere collecting, at least until we finally ended up with unopened CDs and DVDs cramping the drawers in our desks. We gave versions up for the convenience of internet updates. Too soon it all became so easy and routine that the joyfulness often turned into mundane non-spectacle activity... However if you were a part of a particular specialized niche group invested in particular software and its development, a new version could still evoke blood rush in a release cycle.

PC users differentiated socially and culturally (also) based on experiences of access to software updates and agency/ability to install/modify their software in different release cycles. First generations of web-networked retro-computing Amiga and WarpOS die-hards became prominent. Apple (with hardware-clones) users had their own silent Golgota of updates, while Linux-install-fests of the late 90s were all about shared euphoria from Free/Libre/Open Source Software to introverts going slightly more extroverted as a wetware update.

Numerical version naming systems...

When approaching numerical naming of software releases, one could have noticed few general points:

— no (sub) 1.0 versions as an unwritten rule for companies that had marketing departments. There is no need for a first reference to be numerated with 1. Unless...it is maybe F/L/OSS, where a (potentially long) publicly visible path of 0.x development releases, is building both relevance and tension for 1.0 general public use and future fame. Commercial software companies traditionally saw numbering a version ‘1.0’ as a weak point of promotion; they cannot even think of it or don’t want anyone to remember that other versions existed before it. Going public only with a software product's name, when first getting established, is not only enough but also can induce a sense of stability, even more than amending 1.0. Who can blame them, after seeing how many commercial products needed immediate updates as soon as they were released to the wider public? Throughout the late 1990s Microsoft got famously bad for its need to issue patches fast - compiled into second and third "edition" releases, but the established desktop market dominance made them survive those, and normalize them as necessary ‘hick-ups’.

— staging further full number versions is seen as fairly safe to bring consumer attention especially with versions 2.0 and similarly so for 3.0… 2.0 releases are often the most promising and most radical re-work/re-conceptualizations, but often deliver also more revenue, as if it is corrective of not only their technological but also their economic logic/model under the hood. As David Bowie once said: "It is important to be second.", referring to the potential to follow up on hard pioneering work and opportunity to mainstreaming innovation. In the world of software it is often this second version that positions strategically producers inside of its field, or even shapes the field for itself. The most infamous example is possibly the term ‘Web 2.0’ brought in by Tim O'Reilly…

 > #toWriteON: vague promise of WEB 2.0 /hype with exclusively elusive aspirational marketing term, avoiding clarity...< 

— what quickly became obvious was that not much popular attention/PR investment was made for versions within release cycles such as N.xx. These served to satisfy more advanced and expert users that would actually find issues themselves, discuss them and sometimes even report. Putting everyone at peace is what 3.x releases are usually focused on, as the reality check of all compromises and fixing all fixable; practical and pragmatic choices. Both MS Windows^tm and Adobe Photoshop^tm historically carved their status in stone on PC desktops through 3.x versions.

The most famous non-major release in the 3rd release cycle was the HTML standard 3.2 at the moment that the web exploded in popularity and the divergences of many HTML implementations needed to be sorted around common standards in the time of the infamous

>#toWriteON: BrowserWars (x)/between day or a nightbuild - browser wars were what got us into night builds…< 

A notable mention in the version naming here goes to Netscape’s Mozilla browser that served a ‘gold’ version of their 3.x branch which included editing features in the browser, a feature they were guilty of suppressing in their initial release and which established a norm of web consumers, rather than prosumers from the start :-/

While the first decades of the 21st century brought a number of hybrid models of software development and packaging to visibility, it became slightly more complex when products like Ubuntu started to market themselves to mainstream users with x.4 and x.10 in regular April and October releases, projecting a sense of stability and order. While initially piggybacking on the release cycle of Debian’s GNU Linux, Ubuntu added support, packaging and flair that was needed to win over some curious enthusiasts from MS Windows mainstream and later the first corporate and institutional desktop users… Adding the LTS tag for Long-Term Support was a way to state their commitment to a minimum 5 years of availability of updates, it was the kind of innovation that could bring more conservative users also to the table.

The world of auto-naming releases

The last decade brought versioning systems to mainstream technological discussions. Decades of CVS obscurity were soon to be replaced by GitHub/GitLab FLOSS fame. Developers and their releases got a public stage that was comparable to what used to be MySpace and later YouTube for free media content. With the increasing adoption of FLOSS in business, these repositories became code and skill portfolios that centered on individual developers and their work practice. It became less relevant how to pitch and market a particular release as such, at least to expert users and fellow developers. Together with trends of streamlining and automation, came the interest in auto-naming.

“semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package. This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification. Trust us, this will change your workflow for the better. – egghead.io” To cite further: “semantic-release is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be unromantic and unsentimental.”

Interestingly, this announcement ends by linking to a poetical counter-proposal of Dominic Tarr (developer of Secure Scuttlebutt) who shares some whimsical suggestions in “Sentimental Versioning” including the example of node.js punk-rock band: “unstable versions node makes its own rules and sticks it to the man. In stable versions node wears a long sleeve shirt over its tattoos...a beautiful expression of its own internal conflicts.”

Whether to trust egghead.io or to go with sentiment remains a personal choice and/or workflow focus, but what is still important to have in mind is that the assumption is that development is predictable and linear, while history taught us that this is not the only mode and ideally not the only way we can imagine for the future.

World(s) of rare or *(almost) no new version releases

In the existing mainstream logic of linear progress and (often exponential) development as the only way to move forward, it is hard to argue for sustainability, solidarity and counter-competitive modes of production that could consider degrowth as a path. What would that even mean for the IT industry? Would that require a whole new world of values and priorities, one that would create alternative Silicon Valleys? Would that require a radical societal turn in this moment? One acknowledging the toxicity and limits of late capitalism? One with a post-capitalism attitude in quest for new? It is not easy to see a unified path to that, but there is a multiplicity of exceptions that show the necessity and urgency to create more exceptions from the dominant logic. These are below mainstream IT prominence, but visible in their own unique contexts, with urgency to surface and inspire. In elites of technical engineering, one can aspire vertically to the goals of the Software Product Line Engineering for LSS (long-live sustainable systems), a proposal based on extraplanetary space travel needs for the Voyager spacecraft, but relevant to other contexts: “Our society is becoming increasingly dependent on software-intensive sustainable systems. Examples include embedded medical devices, web-based archives, interplanetary spacecraft, power grid monitors, telecommunication switches, and sensor networks.” (...) ”The goal of evolving over time to meet changes in technology and requirements, distinguishes sustainable systems from legacy systems.”

Horizontally, among hobbyists, enthusiasts, FLOSS and access advocates, an ecosystems of projects from retro-computing/recycling/refurbishing hardware to refactoring of closed source products have already showed more than one way to go forward, backward or even staying *(almost) still while developing/maintaining code and issuing releases. A famous FLOSS backstepping example in recent years was the fork of (otherwise no-compromise) Debian done by Devuan GNU+Linux, that insists on not switching to systemd software in favour of alternative init software and other low-level tools, but then also keeps a distance of one year delay with respect to official Debian stable releases. In this non-exciting (FLOSS) development, focused on maintenance and paralleling (with delay) to mainstream Debian, one can recognise methods and approaches (inspired by?) retro-computing developers that work on back-porting software in order to access modern services.

As for less prominent, if not obscure systems, it is the heritage of the 90’s most famous promise of the multimedia operating system BeOS, that before current FLOSS refactoring had a complex version history of forking combined with a kind of spooning efforts. ZetaOS tried to follow up on the development of this abandonware OS commercially, MaxOS hybridized legal, leaked (R5.1d0), free and pirated versions of software as distributions and finally the legalist OpenBeOS that is now still developed as Haiku OS. It’s quite off-stream development mentality can be compared to the complexity of Linux “...BeOS seemed to live in a perpetual state of alpha release.”

Worlding queer/irrational versions...

In the process of recalibrating its vision, Haiku OS held a community poll. After the first alpha release in 2009 (8 years in development) they asked what could be the feature set beyond doing a FLOSS refactoring of BeOS from the late 1990s, and whether to expand their vision to support basic contemporary systems and protocols. Knowing the lack of resources to ever properly ‘catch-up’ with the mainstream, this proposal basically rendered it more or less impossible to reach a stable and operational R1 system in the foreseeable future. An exceptional contributor, back then busy with packaging, but coming from humanities (media studies), presented the state of affairs in a somewhat controversial queering visions talk at the end of 2010 FOSDEM entitled: “Haiku has No Future”. In this intervention he cited the (radical) queer theory of Lee Edelman on queer futurity and Mathew Fuller’s (critical) software studies writing to address the situation and stating that the Haiku OS is a “queer” operating system. “Our work will not ever define the future of operating systems, but what it does do is undermine the monotone machinery of the competition. It is in this niche that we can operate best.” This gives the opportunity for a “playful approach” in development and to keep in mind for next release naming discussions: ”even though we have no future, it does not mean that there will not arrive one eventually. Let us get there the most pleasant way possible.”With a decade of delay, Haiku OS recently released the another beta of R1 and is approaching the next major milestone in its release cycle, where such discussions could ignite again. The constant pressure that developers face from enthusiasts asking for the release date of the 1.0 version, is usually answered with “when ready”. In fact quite a few of the alpha/beta users and app developers became OS contributors while awaiting for 1.0, as they “joined for technology and stayed for community”.

This situation in the shadows of mainstream IT developments, resembles the effects of 'worlding' that Donna Haraway writes about. It asks for non-conventional and bold, non-conclusive trajectories with diverse protagonists and all influencing the (long) now/present of irrational (numbered) releases. In his suggestions Tarr refers to the practice of legendary computer scientist Donald Knuth: “...uses a versioning number system that asymptotically approaches perfection…TeX approach π (the current version is 3.14159265) ... METAFONT approach e ... prophesied that the last change not be made until after the day Donald ascends to heaven… At that point all remaining bugs will be declared features, and the output from TeX will remain the same for all eternity.” and adds realization “...not everyone will understand your intentions...we did not choose the life of the artist for fame and certainly not for fortune - But rather, a dedication to aesthetic beauty and self expression. In this spirit, go forth, and create beautiful versions!.”

Rather than just another new version, we are in need of exploring other versioning and release ordering systems, especially those that go against cultures of novelty consumption and that evoke social/communal and cultural values of care, solidarity and empowerment.

Z. Blace is working in arts, culture and activism, often focusing on technology and its (re)production, deployments and uses in discriminatory/emancipatory ways. Blace likely paid for a software licence (for non-linear video editing app alpha release JeeperElvis! for BeOS) and signed NDA (on a cold rainy evening in Hannover Hbf for YellowTAB's beta of ZetaOS).