- University of Arizona
Bachelor of Science: Computer Science
|# This program is a copy of guff, a plot device. https://github.com/silentbicycle/guff|
|# My copy here is written in awk instead of C, has no compelling benefit.|
|# Public domain. @thingskatedid|
|# Run as awk -v x=xyz ... or env variables for stuff?|
|# Assumptions: the data is evenly spaced along the x-axis|
|# TODO: moving average|
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil