RouterOS version 6.49.13 has been released in the "v6 long-term" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) 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.

This post is just to tell that 6.49.13 has change from Stable to Long Term?
If do tell this in the post.

6.49.13 was released 5 February her:
viewtopic.php?t=204179
i do not see any difference...

Why not make 6.49.14 Long Term. It even have more fixes than 6.49.13

I have upgraded my devices to 6.49.13, but the update check still claims there is a new version with identical version string: What's up with that? Is there a problem with the updating process somewhere?

Can it have some with that 6.49.13 is both long-term and stable?
viewtopic.php?t=204179

Can it have some with that 6.49.13 is both long-term and stable?
viewtopic.php?t=204179

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 have upgraded my devices to 6.49.13, but the update check still claims there is a new version with identical version string:

Code: Select all

[admin@OR8-Switch-KG] > /sys pac upd che
            channel: long-term
  installed-version: 6.49.13
     latest-version: 6.49.13
             status: New version is available

What's up with that? Is there a problem with the updating process somewhere?

I'd appreciate it if someone from MikroTik could comment on this. ;-)

I'd appreciate it if someone from MikroTik could comment on this. ;-)

I think they have a couple of times (on different releases). Has to do with different builds per channel (test/stable/long term).

Hi tdussa,

Can you share output of this command? 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.

You should not rebuild with the exact same version string. That causes trouble over and over again.

You should not rebuild with the exact same version string. That causes trouble over and over again.

As mentioned, only when switching between channels you will run into this situation. As a former developer I really like this approach.

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.

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...

Hi tdussa,

Can you share output of this command?

Code: Select all

/system resource print

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.

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.

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...

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.

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.

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.

forget channels. only version numbers are relevant

forget channels

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.

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?

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.

Hey Normis ... I didn't want to criticise the way changelogs are presented by Mikrotik ;-) I am just unsure. Are the changes from 6.49.11 and 6.49.12 stable also in 6.49.13 LT ? I just want to understand it for myself ;-)
br, Richard

Yes, 6.49.11 and 6.49.12 are older releases than 6.49.13.
6.49.13 contains changes from versions before it, and adds the fix mentioned in changelog.

We could make a Poll about the best approach to changelogs. If one option gets exactly 100% votes, we could consider changing something.

🍿

We could make a Poll about the best approach to changelogs. If one option gets exactly 100% votes, we could consider changing something.

My vote is for:
- put the change lines in a database, have each entry include useful fields like brief description for a changelog line, more verbose description of the entry, category of change (new feature, fix, warning, etc), pointer to documentation, version when the fixed problem was introduced, etc etc (all as far as applicable and available)
- make a website that can query this database and output lines like we have now, but with link that can be clicked for more info when available or show it when hover over the line
- put an extract in forum release topics that shows entries between previous and this version + a link to the changes site that queries the same
- in the router itself, query and show the entries between installed version and proposed new version
- make the query so that unnecessary lines are removed (e.g. when it shows changes between 6.49 and 6.49.13, omit any lines that refer to fixes for problems introduced in versions between those
- when showing a queries changes list on the website, allow the user to modify field like "from release", "to release", "category (all or specific)", etc.
- automate the process within the development system go generate new changes items as part of a change, and have the release manager move them to the publicly visible database. that should reduce work with every new release.

Thats what I like with how VyOS presents changelogs.

The userfriendly edition is displayed at their blog, example:

https://blog.vyos.io/vyos-1.3.8-maintenance-release

https://blog.vyos.io/vyos-project-july-2024-update

But each change also points to their repo over at https://vyos.dev where you can follow the discussions about a particular bug (task) but also what the sourcecode fix was if you wan to dig even deeper over at github.

RouterOS being closed source will be tricky to link to the actual sourcecode however it would be handy with some more details than the currently limited amount of words each change gets today.

If you want to go all in then you have the release notes Arista releases for their EOS but thats like hundreds of pages with almost half a page or more to describe what each bug was and what each fix changes.

Yes that VyOS change list is very much like what I have in mind when proposing the above!

Yes, 6.49.11 and 6.49.12 are older releases than 6.49.13.
6.49.13 contains changes from versions before it, and adds the fix mentioned in changelog.

THX !🙏

Version 6.49.18 has been released.
viewtopic.php?t=214509