RouterOS version 6.49.12 has been released in the “v6 stable” channel!
Before an upgrade:
Remember to make backup/export files before an upgrade and save them on another storage device;
Make sure the device will not lose power during upgrade process;
Device has enough free storage space for all RouterOS packages to be downloaded.
What’s new in 6.49.12 (2024-Jan-22 15:04):
*) console - updated copyright notice;
*) routerboard - added “reset-button” support for RBwAPR-2nD device;
*) tftp - improved invalid request processing;
*) timezone - updated timezone information from “tzdata2023d” release;
To upgrade, click “Check for updates” at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while a router is not working as suspected or after some problem has appeared on the device
Please keep this forum topic strictly related to this particular RouterOS release.
I don’t understand, 6.49.12 was never long-term, and 6.50 will probably never come out,
so obviously now we’ll go forward for example as x.x.13 long-term and x.x.14 stable…
I hope they don’t release 6.49.12 long-term at the same time as 6.49.12 stable to avoid the same mess that happened previously…
Long term normally refers to a branch, or channel, which gets supported for a longer than normal period of time. Long term normally does not simply mean “old version”, and it does not make sense for a single point release to be referred to as “long term”. It also doesn’t necessarily mean “even more stable”, but it does normally mean no new major features get implemented. The long term channel in this case would be either 6.x or 6.49.x. If the latter, you could reasonably refer to a 6.50.x branch as stable, but if 6.49.x is on the long term channel, then obviously so is 6.49.(x+1).
What MikroTik seems to be doing is using stable as a “release candidate” channel of sorts.
Which is exactly how every “abandoned” version ends up (e.g. 7.11). What makes “long-term” different from other random “abandoned” versions is that it’s not abandoned, instead it does receive occasional fix due to security issues. Which means that latest v6 release isn’t that. There are four items in change log:
*) console - updated copyright notice;
*) routerboard - added “reset-button” support for RBwAPR-2nD device;
*) tftp - improved invalid request processing;
*) timezone - updated timezone information from “tzdata2023d” release;
And IMO at least two are definitely not fixing security issues (first and last item), one is highly questionable (support for reset button may fix a bug, but it’s not a security issue per-se) and one I don’t know (invalid request processing in tftp might be a security issue). And due to changes not really necessary this release requires stability testing before installation on “long-term only” devices … which could easily be avoided if MT released into long-term chain only minor changes which are “life savers”.
But then … we all agree that MT’s way of naming chains doesn’t correlate much with what most of users expect … and the lack of decision making is obvious as well. Like: is development of v6 officially terminated or not? If yes, then only security fixes should be done and (after due testing) pushed directly into long-term chain.
Just to confirm by looking at releases last 10 years, 6.49.12 is the first release that going back to stable when previous release in same train was long term.
.
please understand my lack of expertise in this matter. but I just updated my LHGGM 18 Kit to version 7.13.2, it seems to me that this is not what this update refers to (v6.49.12) [stable]
can you enlighten me.
Thank you
Frank52, yes, 6.49.x and 7.x.x are different releases, which you can treat separately. I have older mAP devices running happily on 6.49.11, will soon be updated to 6.49.12, where the more modern routers (more memory, more storage, more functions) run 7.13+
I run 7.13.x (and 7.14beta) without any problems on mAP, mAP Lite, cAP mini (all the same platform).
But you need to be careful with devices only having 16Mb storage. Then it can become tricky depending on config.
what would it cost to produce and sell the devices with 32mb?
Or are there other limitations that make it impossible to provide such an amount of storage?
Historic decisions, I guess.
Somewhere in the past someone said 64Kb was more then enough for any PC running whatever was ever needed. Yeah, right …
(attributed to Bill Gates but never really proven as a fact)
Newer devices mostly have a lot more storage available.
As long as the old configurations are still showing decent sales figures, it doesn’t make sense to kill them.
In some cases they still can be used reliably.
