.NET Core versioning is a mess. There are lots and lots and lots of version numbers, from runtime to SDK, from Visual Studio to languages and of course .NET Standard. So what SDK corresponds to which runtime again? I know there some sort of a system, but it differs per release. Here's my solution:

I called it versionsof.net.

And people seem to like it:

Great web site built by @ArthurRump. Thanks @_cartermp for showing it to me! https://t.co/ob2hxzVeZf

— Immo Landwerth (@terrajobst) December 20, 2018

Absolutely lovely website by @ArthurRump that shows @dotnet versions! https://t.co/kbjoacrwDG

— Scott Hanselman (@shanselman) December 20, 2018

The idea started when I came across some files in the dotnet/core repo: releases.json gives you a list of every release of .NET Core. The reason I found it was the announcement that it was being deprecated, but luckily there was already a replacement in the form of releases-index.json and multiple releases.json files. And then I built a website around those files, simple as that.

Actually, it was a bit more complicated, because the consistency in both structure and content was lacking. If you look at the requests made from the website, you'll notice that they go to my own fork of the dotnet/core repo, because an update to these files might very well break the parsing logic. For the last months, I've almost permanently had an open pull request with little fixes in these files. These issues seem to be mostly resolved now and I'm discussing options to add a consistency check on new pull requests with Lee Coward, one of the maintainers of the dotnet/core repo. I'm hoping to switch over to the real production version of the JSON files in the coming month, once some kind of validation is in place.

Fable

This is the first real project I did using the Fable F# to JavaScript compiler. It's awesome. Being able to write in a strongly typed language with an amazing type system and have a website come out at the other end is just great. Even better: it's a static website that can be hosted for free at GitHub or GitLab Pages. I love it when I don't have to pay for servers.

The only thing I'm not quite a fan of is the tooling setup. Because you're with one leg in .NET and with the other in JavaScript, you have to combine tooling from both ecosystems. I found especially webpack, which seems to be the preferred way of packing up your Fable application, to be very confusing. Turns out you should just copy the example webpack.config.js file and not try to understand it. The dotnet-fable tool tries to make things easier, but a lack of documentation does not help.

I do really enjoy the Elmish programming model. It is so simple that the source code is literally copied into the documentation, and it's actually helpful. Following The Elm Architecture results in neatly organized code, that is also easy to componetize. Code sharing between Fable and .NET is a bit tricky, and I'm still figuring that part out, but at least it is possible.

What's next

As I said, I hope to directly link to the JSON files instead of my own fork. If it doesn't work out, I'll try to add some automatic merging with the consistency tests integrated.

As for features on the website, I'm planning to show the release notes directly on the website, but for that I'll first want to rebuild the table, this time also keeping mobile usability in mind. Another thing I want to add is URL handling for the selected filter. URL handling is also something that is necessary when multiple pages are added. I'll first look into adding .NET Standard, but if there's a good data source for .NET Framework or Mono releases, those would be interesting additions too.

These suggestions are also in the GitHub Issues, which is also the place to add your own ideas. And don't forget to bookmark versionsof.net!