Please use resource on getting a long term 7.x version. As it is now there are new 7.x train every week, but not may bug fixes for current train.
Latest releases that should be followed up
7.1.5 - 22 Mars 2022 (maybe 7.1.6 LT next)
7.2.3 - 2 May 2022
7.3.1 - 9 Juni 2022
7.4.0 - 19 Juli 2022
Lol at this rate, by the time 7.x reaches true stable status we will be on 8.x 
v7 will be a bridge/transitional version to stable only xD
But with changelogs like these, that’s worth it IMO 
Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.
7.5beta4 is on Kernel 5.6.3.
Please use resource on getting a long term 7.x version. As it is now there are new 7.x train every week, but not may bug fixes for current train.
Latest releases that should be followed up
7.1.5 - 22 Mars 2022 (maybe 7.1.6 LT next)
7.2.3 - 2 May 2022
7.3.1 - 9 Juni 2022
7.4.0 - 19 Juli 2022
Its cuz v7 as a whole is NOT considered production ready and I fully support this approach to at least subtlety acknowledge it to the community
PLEASE ADD THIS TO THE FIRST POST !
It will be, in the first post of the 7.5 release topic.
how did you find this? is there a CLI command that shows the kernel version?
Rocket science!
/system/resource/usb/print
Columns: DEVICE, VENDOR, NAME, SPEED
# DEVICE VENDOR NAME SPEED
0 2-1 ADATA XPG EX500 5000
1 1-0 Linux 5.6.3 xhci-hcd xHCI Host Controller 480
2 2-0 Linux 5.6.3 xhci-hcd xHCI Host Controller 5000
7-zip…
This only works in devices that indeed have USB. But all devices use the same kernel version so when you have multiple routers running the same RouterOS you can likely find it from some.
7-zip:
routeros-7.4-mipsbe.npk\lib\modules\5.6.3\
From what I can see, the only changes regarding netmap in Linux kernel 5.8+ were with nftables, but I believe RouterOS still uses iptables and so I don’t think these nftables related enhancements would make any difference.
I’m sure they will upgrade to a newer kernel at some point in the reasonably near future. However, given that they are focused mostly on quashing bugs, I can understand that they might want to hold off on that if it isn’t completely necessary, as the kernel upgrade itself could create new issues that did not exist before.
RouterOS v8 for sure 
New kernel seems a major effort. Maybe now at this moment it is a little easier because they have been working on it recently.
Not really. v6 sticked at ancient 3.something due to routing stuff … if kernel functions (API) don’t change (much), then it’s much easier to upgrade. I’m with @mducharme, I also think MT will stick to 5.6.3 while they port/implement functionality. I hope we’ll see newer kernel later in v7 development.
I think that a new kernel is not a major effort anymore (as mkx said). It was true that it was a major effort when making the move from the old RouterOS v6 kernel, as the removal of route caching was a huge change that required rewriting the entire routing stack. However, we are unlikely to see any such major changes in the near future in the Linux kernel 5.x. The biggest risk in upgrading the kernel in RouterOS v7 above 5.6.3 is unintentionally introducing new bugs, which is why I suspect they would wait until the biggest v7 bugs have been quashed before changing the kernel version.
Why do they stick with kernel 5.6.3? Why not using latest 5.6.19 at least? Makes me really wonder.
Mikrotik heavily modifies the Linux Kernel to support all their hardware. For example, the tile architecture (used in CCR1016/1036/1072) was dropped in Kernel 4.17. So Mikrotik has to manually patch in support for this architecture and keep it up to speed with current kernel development. And the nature of kernel development is such that once support for an architecture is dropped a lot of adjacent functions that may have supported that architecture in the past are removed subsequently increasing the delta with every new version of the kernel.
So Mikrotik has to make a decision whether it is worth it constantly catching up with the Linux Kernel or doing one big push (eg. RouterOS 6 to 7) and then focusing on stabilizing the features against that huge leap in change of function.
And while 5.6.19 may not be that big of a jump from 5.6.3 it is likely that most changes in the changeset do not even relate to Mikrotik hardware. So why bother and possibly introduce negative side effects? Security fixes can be easily cherry picked and backported while leaving everything else untouched. This is not an uncommon way of stabilizing software in the Linux world.
well explained, some people think is like updating a PC typing
sudo apt-get update
or something like that
Well, when the software will be properly stable then, all promise v7 will solve routing problem still not proven yet.
I cannot depend on mikrotik anymore in my environment, i dont think v7 will be stable soon