RouterOS version 6.49.13 has been released in the “v6 long-term” 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.13 (2024-Apr-04 12:57):
*) defconf - fixed firewall rule for IPv6 UDP traceroute;
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.
Of course that is possible, but if I am not mistaken, this isn’t the first time that a release has been tagged as both long-term and stable, so something has changed for sure.
I am guessing that your device is still using the 6.49.13 (stable) version. The 6.49.13 (long-term) is the same version, but rebuilt with newer timestamp and marked as long-term (which is shown in resource menu and used by neighbor-discovery). So if you are 6.49.13 (stable) then selecting long-term upgrade channel will show that a new version is available as expected. Not expected behavior is that you have 6.49.13 (long-term) and it still shows that new version is available in long-term channel.
Looks like developers have a crazy view on this. I am very involved in linux package management, and a version being unambiguous causes nothing but troubles. Versions must be unique!
What happens if you download the version from mikrotik.com/download? Is it “stable” or “long-term”? Does it change over time? That string is not in the download link, so it’s unclear. This can cause lot of havoc.
As explained to you it is unambiguously the same version only recompiled, the important thing is that it is the same source compiled with the same toolchain…
For example all opensource software as used in Linux is distributed in source tarballs and nobody changes the version when compiling it because that would actually create real issues for developers with tracking bugs etc.
And from user point of view if you tested stable version say 1.2.3 when it is moved to long term you know what to expect because it is the same software.
Only people that could have some issues are the ones who mix manual install with system managed updates or stable and long term releases and by issues the worst thing that could happen is that they install the same version twice…
You guessed correctly, my devices have 6.49.13 (stable) installed.
This begs the question, why did they switch to the stable branch? They have all been on LTS for years now. (And obviously it is possible to run into this very problem without actively switching branches. I did no such thing, all my devices have been on LTS ever since I put them into operation. Also, I notice that a few devices that I have only updated yesterday or so did not switch over to the stable branch, so somebody fixed something in the MikroTik side of the update process, I’d say.)
So, I guess that means I either get to “update” all my devices to 6.49.13 (long-term), which obviously means downtime.
Thanks for the diagnosis though! At least I now know what the issue is.
That is just half of the truth. At least two things change: The build time, and a switch replacing string “stable” with “long-term”. Both change the resulting build artifacts, including checksums and what not. And that causes a lot of confusion and troubles. Search the forums, the topic pops up over and over again since Mikrotik started this.
Of course nobody changes the version of source code. But that is out of question. RouterOS is closed source, and Mikrotik has it in their version control system.
But look at the (binary) packages that are provided to the users by distributions. The version strings do differ with every rebuild, even of the same version, as a suffix is appended to the upstream’s version string. This is very important and essential.
I see two ways for Mikrotik to solve this properly:
Remove the channel string from builds, then move the builds from stable the long-term without rebuild. I would prefer that one.
Add a suffix to the version string, for at least one build. Having “6.49.13” or “6.49.13-1” in stable and “6.49.13-lts” or “6.49.13-2” in long-term would fix the situation as well.
As this topic has some potential to heat up… I have given my points and hope this is more or less clear now. I intend not to keep this discussion up.
Question about release notes: Aren’t the changes listed in the first post in this thread very incomplete? Shouldn’t the long-term release notes for 6.49.13 include all the changes between it and the previous long-term release? And wouldn’t that mean that the notes should include the changes from 6.49.11 and 6.49.12 as well?
If I’m on the long-term release chain, the above announcement makes it look like there is just one change from what I’m currently running, which isn’t true. The Changelog list at https://mikrotik.com/download/changelogs is similarly broken and misleading, since the long-term tab doesn’t show you the changes from the intervening stable releases.
Channels are not a bad solution, Google uses them for ChromeOS operating system (with versions formatted as major.minor.build.patch). Just read carefully what’s on your screen and there should be no issues.
Forget it. I had quite extensive dispute with Normis from Mikrotik in this forum about changelogs. And he was very sure, all is OK with them. I believe, he represents Mikrotik’s official position, so…
Is that (“*) defconf - fixed firewall rule for IPv6 UDP traceroute;”) the only change from 6.49.10 LT to 6.49.13 LT?
What about the changes in stable 6.49.11 and 6.49.12 … are they also included in 6.49.13 LT ?
We could make a Poll about the best approach to changelogs. If one option gets exactly 100% votes, we could consider changing something.
P.S: everyone has a different opinion, nothing ever is unanimous. There will be other angry people if we do it the opposite way, as demonstrated in some posts above.