If so, it will be a factory only release as there is no suitable channel to publish it. Stable is already on 7.20+ and long-term is for 6.x.
Yes, it is worrying that there is no “oldstable” or “long-term” channel for v7.
In cases like this were a security vulnerability is published right a the time when “stable” is pushed to the next 7.xx version (so it is only “stable” in the meaning intended for the channels, not in the meaning that users assign to it) the users are basically stuck.
We are lucky that it is not a bad vulnerability for reasonably configured networks… I would not want to upgrade our routers running 7.19.4 and 7.19.6 to 7.20.1 just now. I have to experiment with the BGP upgrade (due to the re-introduction of “instances”) first.
I’d certainly welcome an additional oldstable channel. I think MikroTik should consider adding this well before RouterOS 8.
Stable does indeed not have meaning that users are likely to assign to it. 7.18.1 had 20 changes/fixes only 4 days after 7.18, 7.19.1 had 12 next (!) day and 7.20.1 comes with 22 after just a week and a half. This tells me that stable is merely stable enough for pre-production testing, not for general deployment.
My base update policy is now to install the last 7.x.y patch release once 7.(x+1) is released. For 7.21.y that will probably be somewhere mid next year. Fortunately my devices are quite reasonably configured (no access from the internet, unused services disabled) so CVE-2025-10948 does not make me nervous.
AFAIK there is:
- stable v6
- long-term v6
- stable v7
For all channels: only the latest minor version is in active support (semver vocabulary. 7 major, 20 minor, 1 patch).
And that is the core problem. To OP point, there is no “formal” policy on many of these things.
Now I discount the likelihood of any 7.19.7
Agree should have some “long-term” long ago (or some “previous-stable” channel. Both for consistency and operationally (i.e. if some stable doesn’t work, it a lot more work to revert than picking a new channel)
I think the missing category is SSNRNK.
(Super Stable, No, Really, No Kidding)
But it is difficult to spell/remember. 
Maybe I should write the blog post I wish I could have read, "the upgrade chain, in case you're catching up from way behind". Given how fast the upgrades were, it would not have been faster to learn the nuances and skip more versions, than it was to just upgrade each minor version in sequence—unless I had a single source claiming better.
This seems like an eminently reasonable policy—just, I would like to hear it from them. What's stable v6 vs long-term v6?
My advice would be:
- do not attempt to upgrade from v6 to v7 except as an educational exercise. that is, do an export of the v6 config, do the upgrade, then do a /export of the upgraded config, and save it as well.
- install v7 via netinstall and use the saved config as a guideline to re-configure it from scratch. do not import the firewall, build that new.
When already on an early v7 version, you will find (as @mkx already wrote) that it forces 7.12.1 as an intermediate step. I.e. it won’t offer 7.20.1 on a router running a version before 7.12.
Other than that, there is no reason to upgrade to intermediate versions within the v7 range. There were some issues back in v6 but as I wrote I would not recommend upgrading a router from v6.xx to v7 and then keep using it.
They have described stable as the testing ground for long term. After some time in stable, the same build gets copied to long term.
They didn’t use the word “testing”, but I don’t see how it can be interpreted any other way.
Quoting myself, there is a (personal, debatable) translation table in the corollary to Rule #10
The twelve Rules of Mikrotik Club
[10] Translated from Mikrotikish, Beta means pre-alpha, RC means early Beta, stable means RC, rinse and repeat on a newer version, now you know. (if it ain't broken, don't fix it)