It still doesn’t include 7.21.0.
Thank you for correcting me! I am happy that I can now use this new feature in 7.21:
*) ippool6 - take into account "subnet-id" when specified on address;
This makes my IPv6 life a lot easier.
It does matter. Version 7.21 is available on download servers, version 7.21.0 is not. 
(The drop down just lists the last five versions...)
But I agree that I would prefer to have ".0" appended for new feature releases...
I think it shows the last 5 stable versions. So 7.21 has rolled. The download servers via urls (e.g. if you copy any URL, and replace the version in two places, you'll have that version) will work with any valid version, and 7.21.0 was never a named version.
Now always specify the patch even if .0 seems reasonable. And, IMO, it the download URLs that should accept it at least. These one-off rules make automation a touch more difficult since you need to use a minor for >.0, but not ==.0, solvable but yeah the 7.21.0 as being an AKA be helpful.
Now I think it more aspirational on my MikroTik part... i.e. that a release is not need going to need a patch version. Now MkroTik'ss hopes been dashed every time in V7 as far as I recall (excluding 7.0.x, where it did not start with a 7.0.0).
What I said was this:
I can’t actually seem to find the change log for 7.21.0 on the download page
I’m not talking about downloading the software.
https://upgrade.mikrotik.com/routeros/7.21/CHANGELOG
And again... You will not find 7.21.0 there.
So where on the download page did you find that link?
Here is list of all 7.21 versions:
https://mikrotik.com/download/changelogs?channelFilter=&versionFilter=7.21
Thanks. Missed that tab.
To make it more confusing, I want to know what changed since previous long-term version: https://mikrotik.com/download/changelogs?channelFilter=&versionFilter=7.20.7-7.21.4
The @mkx explained it beautifully:
It has always been about the version - 7.20, 7.21, 7.22, 7.23, and so on. Each version undergoes different development/maturity cycles - development, testing, stable and long-term, with these labels applied at different points in time.
So your filter makes perfect sense if you want to compare 7.20.7 with 7.21.4. You are essentially comparing 7.20 vs 7.21.
It is still difficult to identify the actual changes. Versions 7.20.7 and 7.20.8 include selected changes from the 7.21.x branch. What is really missing is a clean changelog that clearly shows what is new since 7.20.8—and that does not exist.
The closest way to get this information, as described by @ammo, is to parse and clean up the changelogs. However, this is not something everyone can easily do. A typical administrator has to work through changelogs that contain many duplicates.
I think a good solution would be to include a note like “backported from 7.21.2”, which presumably will always be applicable.
I will grant them that it’s not viable to write changelogs taking all parallel branches into account beyond that.
Ok that is nice. Even nicer would be a webpage with two dropdown lists or a list of versions like wiki has where you can tick two bullets and get the differences (changelogs) between them.
It would of course be best when MikroTik did this because they fully know how to parse the lines and what their background is. E.g. add a longer paragraph for some items that could use further explanation, and that can be folded out from the single line shown.
Yes, that is my goal as well. Get all changes between some version (probably the one you are running) and the version being considered to install.
You want a summary of all the changes minus all the issues that were solved and were introduced in a version later than your starting version. Something like:
- l3hw - fixed missing VLAN counters after reboot (introduced in v7.21);
is not interesting when you are upgrading from 7.20.7 so that can be omitted from this aggregate changelog.
And when this log is available as a result of some URL, it can be shown in the router itself as well when checking for upgrades. Now you get a changelog starting from previous version, but of course what you need is a changelog from running version, which may be a couple of versions earlier.
Mine works fine...
How long do you wait for 5GHz wifi to become active before reboot, maybe you are in crowded environment and you set Skip DFS Channels to disabled so it is trying channels that require 10 minutes scan and that could take a long time...
@microchip, did you send a supout report to mikrotik ref your 3011 issue??
Except that was the point. These are just "declaration" or "labels" applied to a build at certain version. Now totally agree the presentation of changes between the declaration/label be helpful/needed...but the presentation issue is it's long to read in current form, "parallel branches"/viability... See RouterOS Schema — Side-by-Side Diff which now shows CHANGELOG between two releases, loosely based on @pe1chl request although these tools really should be on MikroTik's site since they are trivial to do, but helpful
If you ask me these issue is there no "top line" changes anywhere to say "hey we made a bunch of Wi-Fi changes like X, Y, Z; BGP got B, C; etc.". Sometimes in YouTube (or perhaps TikTube) videos on new releases that they sometimes do where in video-form they do summarize changes in video form.
Thank’s for your answer, but I had channel.skip-dfs-channels=10min-cac set for my 5 GHz interface, so it’s not the case.
And I saw no B (bond) letter besides my 5 GHz interface.
Anyway, today I restarted two times my hAP ac2, but I have had no issue with my 5 GHz interface.
I think, that it depends on which channel my 5 GHz interface tries to initialize after the restart.
As time passes by, probably I will have more experience about the issue.