[Feature Request] Changelog and update-channel switching on the firmware update page

[Foroxon]

On the firmware update page it would be great to have:

1. Changelog for the new firmware version — show what's new/fixed/changed before applying the update, so it's clear what the update actually contains (pulled from MikroTik's release notes/changelog).
2. Convenient update channel switching — an easy way to switch a device's update channel (stable / long-term / testing / etc.) directly from the UI, without SSH.
   • Bonus: ability to switch the channel on multiple devices at once (bulk action), for people managing several routers.

This would make the update workflow much more transparent and less error-prone, especially when deciding whether to update right away or wait, and when managing a fleet of devices on different channels.

[hreskiv]

Thanks — both parts are reasonable, and they are at different distances from what is already there.

1. Changelog for the new version

For reading release notes today, I maintain a separate archive at https://mtikchlog.mtik.pl — every RouterOS branch, searchable, with the security-relevant entries marked. MikroTik flags those with !) instead of *) in the changelog, and the archive keeps that flag as a badge and pulls out any CVE identifiers named in the text, so you can filter down to just the security items. It also holds historical releases, not only the current one per branch, which the RSS feed does not.

Inside mikr, the changelog is already parsed — it drives Security → Vendor patches, which compares your devices against the branches where a security fix has landed. So surfacing the release notes next to the version on the update page is mostly a matter of showing data I already fetch, rather than a new integration. I want to do it.

2. Update channel switching

Read-only, this is already in: the Upgrades tab shows the latest version on all four channels as badges, and each device carries a badge with its own configured channel, read from /system/package/update rather than guessed from the version string.

Writing it back is a single setting per device, so the mechanism is not the hard part. Bulk is what I want to be careful with — a mis-clicked selection that moves a fleet from long-term to testing is not something you notice until the next upgrade window, so it needs an explicit confirmation showing exactly which devices change and from what to what.

Two questions, so I build the thing you actually do by hand:

• Roughly how many devices do you switch at once, and how often does it come up?
• When you change a channel, is it permanent for that device, or do you move it temporarily to pick up a specific build and then move it back?

[Foroxon]

A confirmation dialog listing each device's current → target channel, with a disclaimer, sounds exactly right — and only applying changes after that confirmation is the safe default IMO.

To answer the two questions: I recently set up a new hAP be lite and switched a batch of 8 devices back and forth between stable and testing several times, to check Wi-Fi 7 stability while testing-branch firmware for Wi-Fi 7 hardware was still being actively tweaked. I ended up doing it via a bulk CLI command each time, which is exactly what I'd love to have as a proper UI action from the Upgrades tab instead.

So: switches are often temporary (testing a fix, then reverting the fleet back to stable), happen repeatedly over a short period rather than as a one-off, and the batch size is in the single digits (in my case 8) — small enough that a per-device confirmation list would be readable, not a wall of text.

[hreskiv]

That is exactly the detail I was missing, thank you — particularly that the switches are temporary and come in pairs. Going back to stable is half the workflow, not an edge case, and a UI that makes the outward move easy and the return awkward would miss the point.

Single-digit batches also settle the confirmation question: the dialog can list every device with its current and target channel individually, with no grouping or folding, and still be readable.

One part of this is in v1.72.0, the half that needed no write access to a device: the version badges on the Upgrades page, and a "What's new" button on a device page with a pending update, open that version's RouterOS changelog in place — grouped by package, with anything MikroTik flagged with !) and any CVE identifiers first. So the "what am I switching into" question is answerable before the switch exists.

Channel switching itself is the larger half and is not in this release.