It was so unethical that they even deleted posts from other threads—posts that were requesting features in discussions about Beta/Development versions.
However, saved screenshots and social media can help clarify to users of these products the kind of reaction they can expect from this manufacturer.
@tangent - just a thought, why not move the post to a new topic instead of just deleting it?
Just my 10 cents...
If it was a single instance, from someone not yet aware of the rules, sure. But consider the source.
I updated from 7.23.1 to 7.24beta3, and my Wi-Fi kept connecting and disconnecting even after a few reboots; I submitted a ticket with the support file attached.
I will try to recreate the same opportunity that existed on 7.23rc thread...
Opportunity of leave what some thinks is non-related-to-topic behind and talk directly about what I believe being on-topic questions for a beta release.
Where is expected to talk about expected features.
I will take the list initially created on that thread, and mark as done the features that where implemented.
I will remove/adjust some itens that could be taken as offensive by some.
I will keep the separation on control-plane, data-plane, and others...
On the control-plane side of routing itself:
101. Support to TWAMP to feed the Traffic Engineering TLVs of IS-IS or OSPF.
102. Support to Fast Reroute (FRR), at least basic support to IPv4/IPv6. Labels would be great!
103. TE for ISIS based networks. It already works?
104. Auto-cost reference-bandwidth for OSPF and IS-IS. Any chance? Any ETA?
104. Really functional and interoperable with other vendors L3VPN (vpnv6/vpnv4). Without involving dual-stack of LDP.
105. EVPN handling MPLS as transport protocol, and nvGRE if it comes.
106. BGP-LU. Is that dreaming too big?
107. Support to BMP - BGP Monitoring Protocol.
On the dataplane-plane side:
201. [Done] VRF Hardware-Offload[/Done]
202. MPLS Hardware-Offload. VXLAN is done. But what about MPLS?
203. ---
204. L2VPN at least has fastpath, what about L3VPN support to fastpath?
205. Several recent moves smelling good on the aspect of Routing-Rules. Anything coming soon? Flowspec?
206. Hardware-Offload of GRE and adding support to nvGRE. Possible? The HW-OL for GRE seams to be the most feasible of all mentioned. All the Prestera support it, and without doing any search I bet to say that all the other switch chips used in devices that are no in "archive" o products list also supports GRE HW-OL.
207. ---
208. Support to sflow, with minimum extra work to Control-Plane when sampled by SwitchChip. Not Needing to disable Hardware-Offload when you need some kind of flow sampling.
On others aspects:
301. Circuit-ID/Remote-ID, Option82, PPPoe+, TR-101. Customizable RAIO, Appendable RAIO, will be available? String instead of hex, is it possible?
302. Possibility to use global variables on Routing Filters. Any chance?
303. Possibility to trigger an script during the processing of a route on routing filters. Any chance?
304. ISIS on Winbox? When?
305. Bridge with Vlan filtering and ingress filtering enabled by default. Could it happen? Maybe depending on device-mode... Admit-all is always a stab in the back!
306. Real QinQ, real tag stacking(not that placebo of blind tag stacking), Selective QinQ, hybrid port, and all related to that. SwitchChips used supports it.
307. ---
Stop treating release topics as a channel for you to make feature requests.
Release topics are for issues related to that said release.
They do not serve as a free Latvian Golden Fish.
First of all, I appreciate the attitude — acting like a grown man by speaking directly about the matter, without operating in the shadows or resorting to insults.
Well, I don't view this as a feature request.
My feature requests have already been submitted via tickets—mostly on behalf of consulting clients, since they are the actual hardware owners.
I see this as a list of problems that need fixing, with the hope that they’ll be resolved in a beta release.
Take VRF Offload, for instance.
While it solved a massive performance issue, it created another one: the loss of traffic visibility in any Flow Stream format. (Note: I brought this to table since did some lab tests on my own on this.)
Another example? Circuit-ID in hex.
While everyone was busy whining about a corner case where a device wasn't getting an IP via DHCP—monopolizing the thread over a guy who refused to try changing a single command line in a beta/RC release channel (where that kind of user mindset supporting development is actually expected)... It passed almost unseen.
The result? The Circuit-ID hex issue went unnoticed, despite real-world cases where it broke functionality.
Honestly, I’d much rather read serious feedback like this from @fischerdouglas than more “release-topic wisdom” chit-chat like: "2 + 2 = 5 for extremely large values of 2 "
It was proven that they don't have to be that large.
Pay attention.
Still chit-chat and off topic!
Have to agree with @Larsa, a bit.
Although it be better to focus on getting MikroTik to keep improving docs. If MikroTik had some "reference architectures" so there is some "MikroTik recommended design" for the "big networks problems" (DC/ISPs/carriers/SPsetc) that help a lot - then we'all we have some lingua franca for what "right design"... I feel like on each of the dynamic routing schemes + switch-chip has some gotchas. And picking a topology for some greenfield network design with goal use to most performant routing protocols for MikroTik hardware, there is nothing help you in docs today. So I feel like folks have ton of testing/redesigns, to find these "gotchas" down one protocol path...move on to another, to run in different ones. Whereas if there were more documented "golden paths", it avoid the hodgepodge of requests that are borne from trying various architectures with mixed success on some.
I.E. if there were better docs on some of the topics @fischerdouglas raises, we might avoid these discussion in the release threads.
You've been around the block. 
These are not related to the release notes, which are the purpose of the thread.
While I agree you are highlighting real gaps, and normally agree with but... this it's likely counter-productive. For action on anything, I doubt MikroTik is taking notes on post so they get into the developer queue.
And, more generally, IMO, MikroTik responds better to "feature requests" (or perhaps "incomplete features" or perhaps even bugs or non-compliance with standards)...if you have the concrete use case. Requesting protocols/etc without the use case for it... is often a dead end. Basically they want the backstory as justification for some protocol/etc improvement. Or that's been my experience. e.g. A laundry list spanning OSPF/ISIS/MPLS is less persuade than "we use MPLS TE with HW offload and L3HW, on XXX routers, and we see YYY while XXX should be possible on the hardware".
I have ticket SUP-182665 opened two years ago about traffic flow not present about l3hw traffic...... A little tired to wait....
Thanks! Great work!
I especially want to thank you for these fixes:
bridge - fixed local static host entries (additional fixes);
bridge - fixed MLAG MAC address handling issues related to aging, flushing and moving;
bridge - fixed stuck MLAG session when using mismatched L2MTU (introduced in v7.23).
We have been troubleshooting MLAG behavior on a pair of CRS520 switches for quite some time.
Our main issue was that after one MLAG peer rebooted or rejoined the cluster, all links remained up, but some traffic flows became unreachable for 20–80 seconds. It looked like MAC/FDB convergence was not always completed immediately after topology changes, and forwarding recovered only after MAC table synchronization.
On RouterOS 7.23.x we also observed several MLAG-related issues, including network flapping, unexpected MAC address moves between peers, and temporary forwarding problems after VLAN configuration changes. These issues were difficult to reproduce consistently, but they were observed multiple times in our production environment.
We spent many hours testing different bridge, MLAG and LACP configurations, so it is great to see these fixes addressing exactly this area.
Please keep improving MLAG stability, MAC learning, FDB synchronization and convergence times. Many production networks rely on MLAG, and every improvement in this area is greatly appreciated.
Thank you for your hard work!
As documented at Trafic Flow Introduction
Traffic Flow can process only that traffic which is processed by the router CPU, thus HW offloaded traffic will not be seen in Traffic Flow flows
So it isn't a bug you can expect to be fixed but a feature request that may not be feasible for MikroTik to add now or ever...
Version 7.24rc1 has been released:
seems to be fixed in 7.24rc1. The port auto-negotiate to 1G-baseX