Cadence for highlight.js

We're now doing releases of highlight.js on a cadence of 6 weeks. The latest release 8.8 was the second in a row (which is what technically allows me to write "are now doing").

The reason for that is we (well, mostly me) had a certain difficulty deciding when to actually release something. We don't develop new grand features on a regular basis, all that's happening is bug fixes, new language definitions and new styles. And releasing a new version for every little change is going to annoy end users and drive downstream maintainers mad. So releases tended to happen pretty much by chance. Like someone would ask on a random GitHub issue when is the next release and I would think, why not right now?

This anarchic approach actually worked for some time while the project wasn't going too fast. But as this has changed in the recent couple of years and as I've had left users stranded waiting for a new release for months on a couple of occasions I though it's time to get more serious.

Our release process is now quite simple, too. A maintainer only has to document the changes, update the version number and push it all to GitHub. GitHub then pings a certain API handler on highlightjs.org and the site does everything else:

• updates the code,
• builds a CDN package and pushes it to GitHub from where two independent CDN providers pick it up, also automatically,
• builds and pushes a package to npmjs.org,
• updates the live demo and various metadata (version number, language count, etc),
• pre-builds site's caches used for dynamic custom builds,
• publishes version-related news from the CHANGES file,
• restarts itself,
• goes on social media and spends a day generating and over-excited buzz about the release (OK, probably not this :-) ).

The process is still fragile but bugs are getting fixed and it's anyway immensely simpler than doing it all manually.

See you next on October, 20th!