This document has moved!
It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
|// go on you labels pages|
|// eg https://github.com/cssnext/cssnext/labels|
|// paste this script in your console|
|// copy the output and now you can import it using https://github.com/popomore/github-labels !|
|var labels = ;|
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
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
|Swift Programming Language Guide|
|"A Swift Tour" Solutions|
|These are the solutions to all the "experiments" in the pre-release Swift Programming Guide|
|(released on the same day Apple announced Swift). A couple of things worth noting:|
|1. Swift syntax, e.g. array declarations, has changed since I releasd these. So this code will|
|probably cause some errors when you paste it into a playground. Should be easy enough to fix|