Rsclub2_2andClaude Fable 5.1
89d37e62e1
* build: give beta DEB and RPM packages a pre-release number (#113) composePackageVersion is the package version of every Compose target format, so an RPM or DEB built from a beta tag carried exactly the version of the following stable one. dnf, rpm -U and dpkg refuse to replace a package by one of equal version, so a beta user could not move to the stable. Keep the version and tell the packages apart by the package release number, following the Fedora pre-release convention: the new Gradle property linuxAppRelease is passed to jpackage as --linux-app-release (Compose LinuxPlatformSettings.appRelease) and defaults to 1. beta-v1.50.0-beta-001 -> 1.50.0-0.beta.001 beta-v1.50.0-rc02 -> 1.50.0-0.rc02 v1.50.0 -> 1.50.0-1 Everything starting with "0." sorts below "1" for both rpm and dpkg. Nightlies and local builds do not set the property and keep release 1. Fixes #113 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: derive the Linux release number from the tag and verify the tag version (#113) The DEB and RPM jobs now compute the package release from the tag before calling Gradle and pass it as -PlinuxAppRelease: a stable vX.Y.Z tag gives 1, a beta-vX.Y.Z-<suffix> tag gives 0.<suffix> with "-" turned into ".". The result must match [A-Za-z0-9.]+, otherwise the step fails. A workflow_dispatch run from a branch keeps release 1 like the nightlies; nightly-artifacts.yml is unchanged. The test job, which every packaging job depends on, now checks right after the checkout that the X.Y.Z in the tag equals composePackageVersion in gradle.properties and fails with a clear message otherwise, so a mistagged commit fails before an hour of packaging rather than shipping packages whose version contradicts their file name and upgrade order. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: describe the pre-release number of beta DEB and RPM packages (#113) The German and English installation manuals say in the Debian/Ubuntu and Fedora sections that beta packages carry a pre-release number below the stable one, so the stable installs as an upgrade over a beta. The v1.50 changelogs gain the matching "Fixed" entry, and PROJECT_CONTEXT.md records the rule next to the MSI decision. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
KST4Contest
KST4Contest is a Java-based client for the ON4KST chat, developed for coordinated VHF, UHF and microwave contest operation.
The application is developed by Marc Fröhlich (DO5AMF) and since 2026 Philipp Wagner (DN9APW).
Start here
- Project website
- Download Stable, Beta and Nightly builds
- Online manual
- GitHub wiki
- Issues and bug reports
- Development roadmap
What KST4Contest does
KST4Contest combines the ON4KST chat with information that is useful when coordinating contacts during a contest.
Among other things, it can:
- display and filter stations from the supported ON4KST chat categories;
- derive band and frequency information from chat messages and station names;
- maintain Worked and NOT QRV information for the available bands;
- calculate station priorities from distance, activity and other available information;
- manage internal skeds and received Win-Test skeds;
- use AirScout information when evaluating possible aircraft-scatter contacts;
- display stations, paths and additional propagation information on maps;
- exchange information with supported logging programs, Win-Test, PSTRotator and a local DX Cluster interface;
- provide configurable automatic replies for recurring chat requests.
Calculated scores, aircraft-scatter information and path assessments are operating aids. They depend on the available data and should not be treated as guarantees that a contact is possible.
Installation
Ready-to-use packages are available for Windows, Linux and macOS. These packages include the required Java runtime, so a separate Java installation is normally not necessary.
Use the central download page to select the appropriate build:
- Stable is intended for normal contest operation.
- Beta contains changes that are being prepared for a stable release.
- Nightly contains the latest automated development build and is mainly intended for testing.
Documentation
The documentation is available in German and English:
The Markdown sources used for the wiki and the generated PDF manuals are stored in github_docs.
Changes to operating behaviour should be documented together with their purpose and limitations. This is especially important for functions whose result depends on external data, heuristics or information derived from chat messages.
Building from source
Building KST4Contest requires JDK 21. The Gradle Wrapper included in the repository should be used, so a separate Gradle installation is not required.
Linux and macOS:
./gradlew clean build
Windows:
.\gradlew.bat clean build
Repository structure
core/– domain, controller and network code, free of user-interface technologyapp-desktop/– the Compose Multiplatform user interface and the packaging tasksgithub_docs/– German and English manual sourceswebsite/– project website sourcespackaging/– platform-specific packaging files
CI status
Documentation
Builds
License
KST4Contest is distributed under the GNU General Public License v3.0.