Update docs/blog/20240624-Daeraxa-3kStars.md

Co-authored-by: Andrew Dupont <andrew@andrewdupont.net>

Author: Daeraxa

docs/blog/20240624-Daeraxa-3kStars.md

@@ -102,7 +102,12 @@ We had some big tasks ahead of us; changes needed to be made, and work needed to
 
 - **CI and builds:** - We needed an automated platform to build our binaries and run tests. For this, we went with [CirrusCI](https://cirrus-ci.org/), which had a more than generous free tier; it reliably built our binaries and ran our tests for over a year. We have since had to [move away](https://pulsar-edit.dev/blog/20230903-confused-Techie-pulsars-ci.html) from CirrusCI for most tasks, but we still use it for building some of our binaries.
 
-- **Versioning** - Atom's last (at the time) release was Atom 1.60, which left us with some issues. We wanted to stay with [Semantic Versioning](https://semver.org/) as Atom had, but what should our first full release be? We could reset the counter back to 1.0, but that would cause packages looking for a minimum version of Atom to break. We could move to 2.0, but again, there was an issue with packages, which were specifically looking only for 1.x versions, but this time as a *maximum* version. We could continue the numbering from Atom, but this seemed like we weren't getting a clean break as a new project. In the end, we decided to jump from 1.60 to 1.100 - a number that would give us a clean start whilst avoiding the issues with package version limits.
+- **Versioning:** - Atom's last (at the time) release was Atom 1.60. We wanted to stay with [Semantic Versioning](https://semver.org/) as Atom had — but what should our first full release be?
+
+  It’s common for Atom packages to specify `atom` in their `package.json`’s `engines` field — and to specify a version range of `>=1.0 <2.0`. We could reset the counter back to 1.0 — but many packages specified a newer version of Atom than 1.0 because they relied on features that were added in a certain Atom version. We could move to 2.0 — but we would’ve broken lots of packages that had specified a *maximum* compatible version. We could continue the numbering from Atom — but this seemed like we weren't getting a clean break as a new project.
+    
+  In the end, we decided to jump from 1.60 to 1.100 — a number that would give us a clean start whilst avoiding the issues with package version limits.
+    
 - **Electron updates** - This was, and still is, one of our biggest goals for Pulsar. When development slowed in Atom, it caused the Electron version to get further and further behind. At the time Pulsar was born, it was using Electron 9, which went EOL in early 2021. We managed to get Pulsar onto Electron 12, but to go further required some rather extensive changes that are still being worked on. Read our blog post on [The Quest for Electron LTS](https://pulsar-edit.dev/blog/20240124-mauricioszabo-the-quest-for-electron-lts.html) for more information on the topic.
 
 With this work either complete or underway, we made our first tagged release of Pulsar - [1.100.0](https://github.com/pulsar-edit/pulsar/releases/tag/v1.100.0-beta) - on the same day that Atom was finally sunset - the 15th of December 2022.