Darklang release schedule

Paul Biggar -

I remember when I started at Mozilla, and I first got fully sold on continuous delivery. Mozilla had just released Firefox 4, a long and grueling change where some important CSS features had been ready but unshipped for over 18 months before Firefox 4 actually got out the door, slowing down the evolution of the web. After that, they decided to just release every 6 weeks, and everything was much better as a result.

For people who write SaaS, things are much easier. We just press "merge" and the code, through some process, goes to production. If we remember, we write things in a changelog.

With each Firefox release though, we get release notes. We also get release notes for each new version of each package, library, framework, language, database, and everything else that ships as software.

Developers love reading release notes. It's a malady, and I suffer from it. It's great to see what new features products have, even if I don't use the product. It makes for a nice talking point, a good time to connect to your users, and to get seen by people who like to follow along and see what's new (even if they don't use the product).

As a result, going forward Darklang is going to have monthly "releases". We'll still ship everything as soon as it's ready, putting great care into making sure we don't break our customers programs. And then every month we'll put a blog post out saying what we did, and put a version number on it.

Of course, this opens up the most important question: what scheme are we going to use for version numbers.

Option 1: semver-ish

  • Darklang today would be pre-1.0
  • We could use 0.2 (to indicate the rewrite), with 0.1 being the latest as of 2020
  • We'd continue incrementing minor numbers (0.3, 0.4, etc) until we feel that Dark is good, at which point we'd declare that version 1.0
  • After that, Dark could take whole numbers: version 2, version 3, version 4, etc.

The idea here is to explicitly acknowledge the fact that Dark isn't yet a suitable language for writing your startup or company's new critical, high-scale service in. Yet. When we get there, we'd go to 1.0, and have a big massive party. Until then, we'd use minor release numbers, otherwise go along with the Semver meaning of things.

The issue here is that Darklang isn't a pre-1.0 release in the sense of Semver. Certainly, Dark is in public beta, but at the same time, it does actually work. I mean it's got all sorts of problems, but it stays up and people write programs in it and what not.

More to the point, the main quality of semver pre-1.0 is that it allows the authors to make basically any changes to their product/API with no remorse. That's not actually how we do things. Since Darklang is a language designed for continuous delivery, including both apps and the infrastructure itself, we take extra special care not to break things, going so far as to email individual users when something looks off.

Are companies going to want to use something that's version 0.34 or 0.426? No, I don't think so. And though Darklang isn't perfect, we are certainly good enough for many of the small apps that people and companies write, and will continue to get better.

So calling this release "0.2" is inaccurate, and I feel is a bit of a disservice to ourselves too.

Option 2: semver-ish but start at 1

  • Darklang today would be 1.0
  • We would strive for version 2.0, which is what's in the roadmap
  • We'd continue incrementing minor numbers (1.3, 1.4, etc) until we feel that Dark is good, at which point we declare that version 2.0
  • After that, Dark can take whole numbers: version 3, version 4, etc.

This maintains the property that the big release of Dark is version 2.0, which while not required, is kinda cute. It also acknowledged Dark isn't perfect (being a 1.x product), while not being too down on ourselves (if we were a 0.x product).

Option 3: just count up

  • Darklang today would be version 1
  • We'll call the rewrite release version 2
  • The next version of would 3, then 4, then 5

In options 1 and 2, I really don't like the idea of "is this really good enough to call 2.0". I think it's better to just say that Dark today is better than Dark of yesterday, and we continue to get better.

So in this option, we'd pick a small version for the "rewrite" release, and it goes up each time we issue a "release" summary/changelog or whatever it is we do. People are more likely to read Darklang release 35 than Darklang release 1.35.

Decision

We picked option 3. When the rewrite is done (any day now, I swear!) we're going to call it "Darklang release 2". Please go to Hacker News and Twitter and tell us how wrong we were.