 Let's start with how I like the best, which is the story of failure, right? So, these are the versions and the releases of Jason Autodeck. Jason Autodeck is one of the artists whose I am really proud of because somebody has used it in production. So, you know, it's definitely not a work project, but somebody uses it to work, so I'm really proud of it. It generates the A Haskell type declaration from Jason Autodeck. Now, it was really the hobby project, and the hobby project that I released some time ago, and I talked to people about it, and I started adding features. And you see, nearly every release uses this semantic version. Like, major release, that's the major thing, then minor release, and then finally patch level. Where for? It doesn't matter. It's just about versioning another release process that I'm talking today, right? So, if you look at these patch levels, most of this is like, I released the version 2.1, 0.21, about, say, oh, I think the wrong thing. I released version 0.21.0, and then shortly after there was something that I needed corrected because people could not install it, and then another thing that got to be corrected because it worked only for some compiler versions, and so on, right? So, one common way to deal with that is you have 90 builds in Firefox, and you have this system that you basically release this thing, and for the week you ask people whether it's like worthy, a real release, because it was only a power beta, and then you really release it. So, the process, so there are times that I've been working in the bank, I was visibly more diligent. And then it started again because I just updated it, I added a cool nice feature, or somebody asked me to fix a bag, and then I forgot to do all the steps to check the package during the release process, right? And I had like 12 patches, 13 patches in, I think, months. So, yeah, you could say that's what CI should do for you, like testing on different compiler versions and different platforms. Yeah, right? So, I did just that, and with Travis CI, I had the same problem because obviously you need not only to use CI to test it, so I did test that it works and everything is right, but also make sure that the release process, you know, like, you upload everything that you should. So, the next step would be, OK, why doesn't CI automatically upload the new package version when it passes all the tests and it has new version number, right? So, that's what I did for version 2.0 and 3.0, right? Except that it's not really fully automatic when I update the version number. I still need to click that I'm really sure that I want to release it. And obviously, since version 2.0, there were no more patch level issues, except for this one, it was actually testing the change in the release process. Now, the release process is fully automatic, and I can show you maybe how it works. So, first it builds with eight different compiler versions and three different Haskell build systems because, obviously, Haskell has three different build systems now, like Apple, Stark and Pierre, so I test with all of them. Obviously, they are not entirely mutually compatible. So, then after that, it actually uses the distribution that is about to be uploaded with documentation and test it that it works on a fresh Docker image. And then I can enter this... I cannot... I do not load longer release automatically, right? So, I just press the button on GitLab CI and then it does it for me. So, I cannot screw something by doing the release process. There are other people that have this script called the deal that does all the steps as a program to avoid this issue. There is this GitLab CI configuration that you can steal, and I recommend everybody to steal if they feel like that does it for packages. So, if you release a lot of packages or if you just feel like automating everything, including the release process, then just use it. Do you use your own runner? Yeah, I use my own runner. Right. So, GitLab is open source, so you can use the CI runner on your own machine or somewhere on AWS if you have a lot of package versions, that's what I recommend. And since I test with like eight different compiler versions and three build systems, I also recommend it, right? Because that's a lot of minutes on CI. I think they have a limit of 2,000 minutes in three years. So, the next version will also display here besides the warning, it will also display what was actually the issue here and we are adding all code climate and the code quality tools that I know in Haskell to this script because it's obviously very, very useful when somebody sends a pass to you to automatically annotate this path. Oh, by the way, you have your unused function and by the way, you didn't even comment on your path, so I don't really know what you are doing, right? And then people get also better, like they respond quicker to the issue because they feel like machine pointed it, so it's not personal, right? GitLab CI is the real limit of normal types you can run. You can always have GitLab CI installed on your own machine, no problem. No limits, yeah. And you have GitLab run and you can install on your own machine, right? That just does CI for you. Oh, free? I think for the cost of 2,000 units per month? Yeah. 2,000 units per month, you mean in the local? Yeah, it goes really fast. If you are active developer, then you usually make, I don't know, 10 or 20 commits per day and then all the GitLab and some of the bits can take like 8 compiler versions to the Git systems is like an hour of minutes, so that will go really fast. 2,000 minutes is for small projects. Do you have more files, please? Yeah, yeah, sure. So the young file here, it is basically stages. Then the variables I really should use, but I don't. And then it's important part of statement that you are caching the sandboxes or npm package files or something like this. Then there is a generic bit script. This is this one. This is cabal version. Cabal is like npm package. So it checks the compiler version, the cabal version for debugging and then it uses default image. I always use like pre-built image on Docker. That's also automatically built so that I cannot screw it by releasing the wrong version. And then it builds documentation at the end. And there is this customization of the build system with different THC version variable for each of the versions, right? So we use yaml variables or yaml include to do this. So dot buildX is actually yaml template, right? That we expand with changing the values of some fields, right? In this case, variables. Each of these builds uses the same dot buildX, right? And then you can also indicate that you upload the packages as artifact. So anybody can download this version that was built. In this case, they expire in two weeks. So if you want to make it release after build, you need to do it within two weeks because these artifacts are also used for the release, actually. Any more? Any more questions? This is all open source I recommend looking at. Even if you don't use Hatchel, you probably want to have a give-up CI script of this kind because it's really short. At least release process you can automate to NPM, for example. Okay, thanks.