Operations

Plan and verify Icecast upgrades

Separate Icecast releases from old documentation labels, plan a 2.4-to-2.5 update and verify authentication, TLS, relays and rollback behaviour.

On this page

A version label on a documentation page is evidence about that page, not a guarantee about the executable you installed. Record the runtime version, package/archive origin and configuration baseline together before an upgrade.

The source situation at 23 October 2026

The official download page names Icecast 2.5.0 as the current release. The documentation index’s “latest” and “trunk” links still displayed 2.4.1 when checked, while the 2.5.0 archive contains release-labelled documentation and newer configuration examples. Even the archived 2.0.2 authentication page labels itself 2.1.0. These inconsistencies are reasons to compare sources, not to silently treat all their claims as current.

The official support announcement says upstream support for 2.4.4 ends on 31 December 2026 and that only security fixes are accepted until then. Distribution maintenance is a separate policy. Do not assume an old package has the same support as the latest upstream release, or that a distribution package’s version string describes all its patches.

Review meaningful configuration differences

The 2.5.0 example contains role-based authentication, <upstream> relay blocks, <yp-directory>, event bindings and a TLS context under <security>. It names log levels and uses destination for aliases. The parser still handles many older layouts and emits guidance for obsolete forms. Read those messages during a test; do not rewrite every working setting blindly in the same maintenance window.

Windows GUI descriptions and platform lists in old manuals are historical material. They do not establish support for an obsolete operating system or describe today’s installer.

Prepare a reversible change

Back up the executable/package identity, full configuration, required transforms, user data and service settings. Run the target release on separate local ports with copied non-sensitive test data. Check startup, each source type, listener authentication, public data, metadata, relays, fallback/return and TLS. Confirm custom scripts and callback contracts before enabling them.

Define the rollback point before switching: restore matching executable and configuration together, including any changed authentication data. A parser accepting the old file is useful compatibility evidence; it is not proof that every integration and active listener will behave identically.

Sources