Lately, this question came up a few times on different channels and I felt to provide some background why things are the way they are.
The question arose most likely, because the latest KMyMoney development snapshot downloaded had a problem and users using that snapshots wanted to return to an earlier version which did not have this problem. At that point they just found out, that those older versions are not available anymore. Therefore, this post will provide some information how the KMyMoney project handles development and which services create binary versions and why older ones disappear.
For that purpose, I created the diagram shown below. It shows the participants in the game enclosed in the areas identified by dashed lines. Those are:
- KMyMoney developers provide the source code that makes up the application
- KDE project and their sys-admins running the CI/CD infrastructure which is used by the KMyMoney team to verify that the software compiles and builds in various environments (Linux, FreeBSD, Windows) and provides executable test versions (snapshots).
- The distribution maintainers who use released source code versions, add distribution specific changes and provide the installable package in the format for the distribution in question (e.g. RPM, DEB, AUR, TGZ, …).
The diagram also shows the means that the various players interact with, namely the GIT repository and the released source tar-balls. And last but not least, it marks the different steps in the processes of snapshots and releases (red circle with white number) which are explained below.
Step 1 is where a source code change happens. This may be a new feature or a bug fix. The developer commits this change to the GIT repository either into a specific branch (e.g. stable or master). I leave out feature branches which also exist but don’t play a role here. Once step 1 is finished, automatically
Step 2 kicks in and the KDE CI/CD system starts a pipeline to build the software and run the automated tests in various environments. In case any of those builds or tests fails, the committing developer gets a notification via e-mail and has the chance to fix the problem by adding another commit in step 1 and thus restarting the process. If all builds and tests finish successfully, the last part of step 2 creates installable versions for different environments as snapshot version and continues with step3.
Step 3.stores the last successful build for download by developers, testers and interested users. Per KDE project policy only the last successful build is kept, which answers the title’s question. Those snapshot versions will show a version x.y.z followed by an 8 digit hash in the Help/About KMyMoney dialog. This 8 digit hash identifies the commit (step 1) that this version is based on. Example: 5.2.1-05390aa93
Steps 1 through 3 can happen multiple times a day.
Step 4 happens, when the KMyMoney developers (or better release manager) create a release. A release does not only contain the source code in a compressed container format and an electronic signature as outlined above, but is also accompanied by the releases notes, change log and the public announcement on blogs, mailing lists, forums, etc. So a bit of work is involved. Step 4 also includes the change of the version number of KMyMoney (which is another step 1 commit) and creating a tag in the GIT repository on the commit that is used to create the tarball. Binaries created based on those tarballs therefore do not show a commit hash in the Help/About KMyMoney dialog.
Step 5 is performed by the release manager with the help of KDE sysadmin. KDE sysadmins take the files and add them to the KDE content delivery network which comprises of mirrors around the world.
Step 6 happens, when distribution maintainers take those source code files and compile and build them into installable packages for their distributions.
Steps 4 through 6 usually happen at a low frequency.
I hope that this explains how the project works and why things are the way they are.
Not shown in the above diagram is the work performed by one developer. He maintains a specific build for MS-Windows versions based on MinGW. Using cross-compiled versions allow to create KMyMoney for Windows including support for AqBanking (online banking features) which is not possible using the MSVC compiler suite. Since he basically uses the above mentioned steps 4, 5 and 6, the resulting binaries unfortunately do not contain the 8 digit hash in the Help/About KMyMoney dialog.