All reports are always considered by mods.
I miss my 2-stroke car engine. Pushed to use lead-free fuel. So sad 
EDIT (as post was tagged as OT):
No changes implies technological debt that should be treated as step back.
Especially if many of users do grumble that MT's mgmt tool has been so old fasioned and there is a need for "something fresh&new" like .... and put there the name of any brand you wish.
Don't start your own offtopic posts, maybe?
https://forum.mikrotik.com/t/7-25-stable-is-released/273987/118
If we treat it literally: yes.
As a comment that no changes implies technological debt that should be treated as step back: no.
Especially if many of users do grumble that MT's mgmt tool has been so old fasioned and there is a need for "something fresh&new" like .... and put there the name of any brand you wish.
EDIT:
Edited referenced post as you seem to be a little overreacting.
Should be post of "pushing to use WB4.3" from this thread removed and all other "noncompatibile" posts? Aren't the connected to 7.25 version.
Let other mods to decide. I should not be a judge in own case.
Some of use come here for the banter... It the main release threads is where this is a problem. Thus, the fork here. The converse equally true: if moderates delete post or overly police things, there equal number of complaints about censorship.
I think the major gripe for some people is that MikroTik router configuration is at a too low level for them to learn and understand, and they want a higher level like offered by Ubiquiti, AVM, etc.
Something where you can configure a functionality in a single wizard or on a single webpage.
It would be possible to have an admin tool that does that with MikroTik devices, but it would have to be completely exclusive from what we now have in cmdline/webfig/winbox. There would probably have to be a global flag that indicates in what way the device is being maintained, and it would have to be decided at reset-configuration time.
The current "Quick Set" is a half-hearted attempt at this, and it clearly shows that it is impossible to have both that and the usual MikroTik configuration. I have asked many, many times for ways to disable Quick Set (e.g. make it a separate package that can be uninstalled, make a global flag for it) but it has never been honored.
@AmmO according your post: Just thinking how to react in this thread? Tough decision, really tough.
In the release topics there was always this mention:
Please keep this forum topic strictly related to this particular RouterOS release.
And still is.
Nobody cares about your 2-stroke car engine in a release topic.
That easy.
As nobody cares about complaints on WB4.
Don't you overreact? 7.25 [stable] is released! - #118
I'm not a moderator, so I can. The conversation was fork. Job well done. If someone care to they could start a new topic on what every thread here they wanted. Once you hijack a thread, and moved, well that's archive to avoid "censorship", and for those that want to continue same thread... but "forking" is also indication someone could start anew in a new topic on their potifications about what MikroTik must do, if they want to control the discussion/direction of a topic.
On the topic, if folk don't think MikroTik knows it hard-to-use for those starting, you're crazy. I'll offer MikroTik sometime implements feature suggestions that are practical/actionable. And the fact that they can't break anything if they add/change stuff make improvement slow and in small pieces. Like CMR, it's going to take a few minor releases but that offers hope on the configuration front as there is a new "home" for provisioning. It's currently run-script, but I trust MikroTik when they say "they have plans"... but you have to have some core things to be secure in that, so that takes time.
Am I? I just found the timing highly ironic. You moved a massive wave of off-topic posts then immediately resurrected a three-day-old comment just to reminisce about your 2-stroke engine. If pointing out that contradiction is an overreaction, then sure.
A new configuration layer could be made by another company than MikroTik, possibly using AI.
What some users need is a way to accomplish often desired tasks, without having to dive into networking details. "I want to have a guest or IoT network". Sure:
- make a VLAN
- put an IP address on that VLAN
- configure DHCP for it (one of the few tasks for which a wizard exists that can perform the several steps)
- make adjustments in the firewall to properly isolate it from the home network
- make a virtual WiFi interface and configure it (SSID, Password etc)
- make it member of the VLAN
Piece-of-cake for someone who understands networking, exercise of several evenings for the dad who bought a MikroTik instead of a Draytek, FritzBox or DreamMachine for the home network.
What he needs is a simple "create guest network" button that asks for an SSID and Password and does everything required.
And sure that can be created when the configuration layer knows that the router configuration entirely is as expected and as it would have created it. It is same with Quick Set: as soon as you make changes yourself, doing another thing via Quick Set will destroy the configuration. When you do not make changes, Quick Set is fine. But it is extremely limited in what it can do, so not suitable for many to manage the entire config.
There already big part of such a tool is prepared: Free RouterOS configuration generator (browser-based, no account) but the configuration should be applied somehow.
There is no problem with WB4 per se as it was made more or less OS agnostic, refreshed, has to mature enough and is an extremally usefull as a tool to manage MT's gear. MAC connection is a all-time game winner comparing to other brands.
Even if a new "setup wizzard" would be incorporated into it, the problem remains: complicated low-level tool is needed to be use and there would be always a problem of changes made after the initial configuration as QuickSet or a new QuickSet++ do not reflect these changes.
You wrote about a tool for "I do not know anything about networking" but bought overcomplicated pro-like device and I I'm overhelmed with and it's configuration possibilities.
It's totally different problem that could be solved,new tool created but then we would be definitely back to a problem: "I need to tweak this, that and other that but I do not want to learn anything and why a wizzard does not help me?". That leads to a tool that separate users from internals and it would be another "average consumer layer", not the professional layer.
BTW ...
Don't we drift out of the "stable releases" topic? Shouldn't it be in a WB4 category or a new one?
I can perfectly understand that and I, too would appreciate a single pane management view of an entire Mikrotik network. Like e.g "create VLAN, connect with SSID, done" on all managed access points.
Yet I am somewhat schizophrenic, couple of friends always wonder why I am so in favour of UIs for e.g. my NAS (TrueNAS, Sylve), my firewall (OPNsense) etc.
Well I like getting an overview of the state - all the state - with a single look. And when creating new artefacts like a new VLAN and a DHCP range and firewall rules etc. I also find a UI that shows me what is there, what I am about to change, and what will be there after the change preferrable.
Yet I have more than three decades of Unix and Cisco IOS on my back. I manage a fleet of >100 servers with >1000 customer jails (FreeBSD native containers) running on them with Ansible. Etc. So that's what puzzles my peers - why not go CLI entirely.
No idea, I just enjoy using a well thought out UI. And I have high standards having been not only a FreeBSD but also a Mac evangelist for three decades, too.
Why am I writing all of this? The point I want to get to is that MT first and foremost need to fix their CLI. Nothing in the CLI specifically but the documentation of it. Let me explain.
There is no exhaustive reference guide. Their entire documentation lives on examples. This has been very frustrating to a point I almost gave up on MT.
Example: I just ordered my first MT device for my homelab, a CRS326-24G-2S+IN - great small switch with a great price - and I want to set up LACP ports, VLANs on top and the like.
Documentation (to this day):
/interface/bridge
add name=bridge1 frame-types=admit-only-clan-tagged
Hey! Waitaminute! I don't want to create a new bridge. Didn't your documentation explicitly say not to create more than one bridge or I would lose hardware accelerated forwarding? I have a bridge. It's named "bridge". It's in the factory configuration.
Only with an exercise in patience, trial and error, and a solid foundation of networking already present did I manage to finally understand (I think) almost everything bridging/switching and layer 2 related. Including using VLAN 1 (Jehova! Jehova!) because I want to and there is nothing special about it other than "export" not showing it in various places.
How is someone who is not a network engineer by profession ever going to make sense of the docs?
Have you seen Cisco's? In print? IOS 10.3 reference guide. Two shelves full of paper! I am not suggesting printing that stuff again but even online IMHO Cisco still is the quality we should all strive for - documentation wise. [1]
So what would I wish for? I tried a couple of the external web based config management tools. Unfortunately they all failed for me. Mikr for example frequently blew up over VLAN 1.
Told you! Don't use it! It's in the FAQ!
No. Sorry. If you have your native VLAN on the trunk ports under control there really is no reason not to. It's just that "export" doesn't show it. And so that tool showed the interface in question with "no VLAN". I'd say that's a bug, not me holding it wrong.
Cisco IOS BTW does similar things.
So what would I wish for? An Ansible module that is worth the name. There is Ansible for Cisco IOS and interfaces, VLANs, LACP, ports, IP addresses, routes, ... are all first class artefacts in Ansible. Which means you can say e.g.
vlans:
2:
name: dc-admin
[...]
name: Ensure device has the complete list of VLANs
ios_vlan:
vlan_id: "{{ item.key }}"
name: "{{ item.value.name }}"
state: present
loop: "{{ vlans | dict2items }}"
notify: save startup-config
name: Ensure retired VLANs are removed from device
ios_vlan:
vlan_id: "{{ item.key }}"
state: absent
loop: "{{ vlans_to_remove | dict2items }}"
notify: save startup-config
See? Ansible knows what a VLAN is in IOS. "vlan_id: X, state: present". Nowhere is there an IOS command in that play. The module does that. And idempotence - one of the most important concepts in Ansible - is preserved. If e.g. the VLAN in question already exists, Ansible will not issue the commands that create it again but simply output that as "ok" (green by default).
The Ansible integration for Router OS on the other hand just lets you send CLI commands to the device. The Ansible module itself has no clue what Router OS is.
So my more or less only wish before we even think about fancy UIs - what about building an Ansible module that is worth the name? And possibly fixing the documentation while we are at it.
I'd be willing to contribute.
Kind regards,
Patrick
[1] About ten years ago we gave up our own DC and multiple BGP uplinks and switched to a contractor implementing layer 2 and IP uplink for us. At the time the default free zone blew up past the capacity of the Catalyst 6500 platform and we were looking for alternatives because more modern Cisco gear was entirely unaffordable for us. We had been living on refurbished 6500 comfortably for some time.
So I wrote to both Mikrotik and Unifi asking if any of their products was capable of managing multiple uplinks with full tables. Never received an answer.
Mikrotik definitely did look more appealing, but even back then - I was searching for an exhaustive BGP reference for Router OS. Interested in if they could do route maps, AS path prepend, and all the stuff you need when peering. Dear folks at Mikrotik - network professionals need reference manuals. Every single command with every single option explained - not by example, but in detail with all the background of the inner workings of the product. Please. 
This will probably never became reality. They're trying with manual.mikrotik.com. Even when the changelog says "hey we've rewritten the whole x and verified by true device and whatnot". It is still the same old
Mikrotik docs is written like the Mathematics books from my school time: A new topic is explained by very basic and simple examples. And then the tasks right below are completely different.
I have some hopes in their CLI documentation which is in the making. But we'll see.
Annakin: We have a CLI
Padme: And you have a formal specification for it, right?
Annakin: 
Padme: You have a formal specification for it, right?
EBNF or whatever doesn't matter. They have a spec from which a documentation can be generated that "just" (yeah, it is work) needs filling out the explanations?
What they need is some reference architectures for the various BGP, OSPF, ISIS, etc topology, since I understand attributes but I always feel like I'm guessing at OSPF/etc since there are for sure good pattern and bad patterns. The config/CLI/attributes that are flat, so no way to separate the right approach just all of them. And this become more important since some features change depending on the hardware, so the answer changes... but that take cross-references the switch chip pages with the protocol pages, and the work back to the CLI Reference arguments. Someplace, the info is all there, it just in different spots. Side note, with AI, it's better at unwinding the docs since it can keep the half dozen pages needed all in context.
Another victim of pre-WWII German technology 
While indeed many sections of the manual are just examples, there are also a lot that enumerate every possible setting to explain it. It depends a lot on what area of RouterOS you are looking at. I remember that I once looked up "how does simple queue work" and indeed there was nothing at all in the manual, the entire simple queue section was just a trivial example of how it could benefit you, but nowhere did it explain what all the other options (not used in the example) are for.
In some cases (also for queues) it helps to have generic Linux knowledge and know what underlying Linux mechanism you are in fact configuring, and how the RouterOS keywords are probably mapped upon the Linux features. But of course that is not how it should be, when you manufacture and sell an independent product derived from another one you still need to document it, even when that document is just a link to some external document describing Linux.
The problem also is that it is a thankless task to spend effort on documentation. There probably now is a team that is doing support all the time and a big part of their work is helping customers who do not understand how to perform some configuration task, however when it would be very well documented the amount of work likely would hardly decrease. People do not like reading documentation when they can ask someone else.