Does this issue only occur in v7 or does it happen in v6 too? To fix this issue, is it enough to just upgrade the RR v7 to the latest 7.x version, or do we also have to upgrade the peer?
It's routerOS for network related stuff, protocols...?
Or it's appOS for easy deployment on homelab?
Many improvements for app side... Maybe too for me.
"Liberate tutemet ex inferis" is a famous Latin phrase from the 1997 sci-fi horror film Event Horizon. It translates to "Save yourself from Hell" ![]()
Maybe this just means that future release candidates will be published under development!? That would actually be a good idea. An announcement explaining this change would also be a good idea. We'll see.
Maybe MT is finally admitting that they don't do any testing? ![]()
La battuta del mese, bravo!
Why show version that is older than in other channels?
I think I think it can also be removed from here.
Exactly! It should not!
And that's why [TESTTING] should contain at the beginning of a release the BETAs, and in sequence the RCs, of the SAME version.
Considering that there are the users that want/need to TEST the things, and report.
And the [DEVELOPMENT] should contain what is under development epoch, in time to approach missed aspects of innovative features an working methodologies. And bring suggestions.
But I believe the most important point in this matter is who should be using these versions.
I interpret Mikrotik's move to hide the Testing Chain as primarily to avoid arguments from inexperienced users who suffer from "click-happy finger syndrome" and end up clicking where they don't know and putting things that are in [TESTING] or [DEVELOPMENT] into production.
Instead of hiding the chain... Impose a restriction that to be able to choose the [testing] and [development] chains, this must be explicitly enabled via device-mode...
This will make it less likely that click-maniac users will fall into a hole they don't know how to get out of...
And at the same time, it will bring the users who really want to get involved closer to the testing and development phases.
No, have existed in the past
The smartest thing I read today.
What are you talking about? Sorry I did not understand anything.
Maybe it helps if i explain in plain terms, so we have these release channels. Stable, Long-Term, Testing, Development.
If we release 7.23 beta 100 as "Testing" and later release 7.23 as stable (but it's newer and more mature). Then it is reasonable to hide this old 7.23 beta 100.
This has nothing to do with "testing" anything. Those channel names are just names.
Hope this clears up the confusion.
(for me there's no confusion, just other users expectation, that's what users are expecting from merely names...)
I will try to explain my point of view taking as example hypothetical(invented) future versions for the chains...
Let's say we are at
- Long-Term: 7.49.3
- Stable: 7.51.2
- Testing: 7.52-RC3
- Development: 7.54-ab349
Tanking as reference the history of releases of RouterOS by MikroTik, is correct to say:
- We wont see a new beta for 7.49. Considering it is already on LTS?
- We also wont se a alpha for 7.51. Considering it is already on stable?
- We also wont see a new beta for 7.52. Considering it is already on RC?
So:
- [Long-Term] - Its always an stable that has demonstrated mature enough to be promoted to LTS.
- At max... A new patch sub-release to small fixes.
- [Stable] - Release as Stable, and Sub-Releases in corrections/patches.
- [Testing] - Beta an RC, with the pre-supposed that no bet comes after an RC.
- [Development] - Special cherry-picked alphas from nightly builds to allow more experienced users to use it. Or even to some users test corrections made resulting from support tickets.
Device-mode Release-Chain "Anti-Pervert-Finger-Updater-Lock" would avoid over excited/unexperienced users.
Well, MikroTik is at step 0.5 in @fischerdouglas plan. The channel should be progressively newer. And now www site at least prevents someone from downloading the rc from what is now in stable. So that is progress, IMO.
Now does not fix the need to switch channels between development/testing as beta/rc progress. And, since RouterOS uses same channels as before, you can still accidentally be "testing" an older version than "stable". e.g.
curl -s https://download.mikrotik.com/routeros/NEWESTa7.testing | awk '{ print $1 }'
==> 7.23rc4.
IMO, it's the 7.23.x+1 patches that should make a stop in the testing channel. And if a channel is older, the NEWESTa7.<channel> should just return the new version that replaced it. e.g testing should equal stable at this point in the cycle.
Basically, being able to leave a box on "testing" and get the RCs, then when those go "stable" also provide those stable releases in testing. Until a new RC appears, then switch testing to that RC.
Please do not be so strenuous.
ROS has been like a box of chocolates, you never know what you get but you can be exited again and again every time you unwrap a new one ![]()
sorry for bringing this up.. but I just noticed Linux 5.6.3in the resources -> hardware list.
That kernel was released in April 2020... very impressive they're still maintaining it?
Not even trying to be snippy. I'd imagine backporting patching for not even a LTS release (5.10 is the oldest LTS) would be a real pain in the ass.
If it works, it works?

