Yeah, the deal with pre-releases and releases is pretty simple, same as
@AndreTen summarized.
In the beginning, releases served on GitHub were created manually, where I uploaded binaries compiled on my own machine, wrote the release notes etc.
Some time after that, as the project grew, rightful concerns were drawn about how safe these builds are, plus, it was getting tiring to always have to upload binaries myself, otherwise people had to set up their own build infrastructure to keep up with the upstream. GitHub offers a configurable and free service where it can build the project for you, and also upload binaries etc. Basically an automation. Builds are done in virtual machines that are reset after every build, so they’re in a clean state. So it was natural I implemented and switched to that.
That’s what the industry calls CI/CD. Aka continuous integration, continuous deployment. The idea that modern software is continuously worked on and deployed with customers that test it, report issues, those get fixed and so on. It’s not about whether the testers are internal or external (like Windows Insider), but rather the fact that the same testing is done all the times. Idk, I don’t fully agree with that, the classic approach is still fine depending on the project imo, it meant working in a so-called sprint, pile up features altogether, some versions may have got broken but you keep adding, at some point you say stop, and from there on there’s another period or only bug fixes and testing. Yeah, here’s not that much the case of either approach, but rather building with GitHub filled nicely the other concerns above more than adhering to the CI/CD philosophy per se.
So I switched to that. And it made sense to have it build the software every time I pushed a change to the repository. Then, what next?
At first, I set it up to also create a release every time I pushed things. At some point immediately after I realized that can be quite troublesome, as some changes are very minor, some may break stuff unintentionally etc. I mean, Git also has branches, think like snapshots of the project at some point upon which you work and implement or test something or whatever independent of the master branch. But it did not really make sense here, as a lot of the stuff, I knew it had to land in master, it was something to implement, it just took a while and a few tries (read: commits) until done right. And yeah, initially all that generated a new release.
Furthermore, when I implemented the updater, it was natural to have it serve releases from GitHub, I did not want to create and maintain a separate infrastructure, it did not make any sense to me. But then it got annoying when I wanted to push several commits a day and people got 3-4 updates a day, and most contained just small stuff, incremental changes. That with me also piling up commits locally, as I observed I was keeping commits locally for more, because I understood it was disturbing to push too often. But that doesn’t make sense: what’s the point of a remote Git host if you delay pushing to it, both as a backup, as well as for others having access to and collaborating on the latest stuff?
So then I said, okay, I will have it stop building releases on every push and cherry pick myself some commit and build releases for that using GitHub’s infrastructure. Like, it became especially annoying with the updater because it made it so painless to get new versions, but on the other hand, sometimes I may, by mistake or as a side effect, break some things etc, and it was quite annoying to have that happen for people not interested in testing, I admit that.
And that’s largely how it is today and is pretty logical. But, even better, some people got used to having instant access to builds containing the latest additions minutes after it was pushed, so some were not so happy if I were to stop that. So then, I thought, let’s have it build the software on every push, but publish that as a “pre-release”. That’s not what the home page offers, you have to seek it out in the “Releases” page or manually opt in in the updater. This way, whoever is interested in the latest and greatest as soon as it happens can use that, with all the ups and downs of that approach, while for general usage, I handpick some version from time to time and promote that pre-release to release status, and that gets offered on the home page etc.
Now, the order in the releases page is controlled by GitHub and may sometimes go crazy, I can’t do anything about that.
Regarding file versions. These basically mean nothing, but are kept there because people are used to “versions”. What really matters are commits. Every time I push a commit, a pre-release is built, as I said. A commit is identified by a SHA256 sum of its contents, and is rather unique as far as a project is concerned, which is what matters. The version of a pre-release on the other hand, that is taken from a file in the source code. I update that file manually. And the version is incremented every time something relatively major happens. Ofc, as someone above noted, I don’t increment that with every commit, as it doesn’t make sense. They are a general indicator of around which commits a version is based on, but not an exact pinpoint. If I fix a typo, it doesn’t make sense to increment the version, for e.g. the difference in nature is infered from the commit SHA256, the version still indicates the same, as it is basically the same, understand what I mean? I would use SHA256 commits as release names and versions, but that’s less human friendly and not really supported by the executable format in Windows, but mainly not as human friendly. Also, it’s not that often that I push without bumping the version, but it indeed happens quite a few times.
When will be the next release? Idk, seems to me current pre-release builds stabilize, so I’d say soon. As mentioned, I also saw how a new Windows CU is or was just released, so the timing aligns rather well. There were some rough edges with the first few pre-releases after the current 39.1 release. I think it was good that those versions reached only the people willing to test. Now that the stuff is ironed out, there’s bigger confidence to push it to everyone without fearing that this here or the GitHub Discussions page will explode.
Are releases 100% bug free? Ofc not, I am still a single guy “battling” an army, but I am doing my best and mitigating and trying to improve it as best as I know.
The Windows 11 Window Switcher is just a bad joke in comparison, it's actually quite sad TBH.
