@Mikrotik
I let you now that changelog not is complete.
Just date but nothing else more

Be patient. It's normal that they don't know what changed at specified version

Be patient. It's normal that they don't know what changed at specified version

Really?
Why would Mikrotik post a version change without knowing what content changes were made?
Why would anyone download a new version without knowing what changes were made.

Because just that. We see this everytime. That's how it goes here.

Plausible deniability?

They issue a patch that might or might not solve problem of some particular client, change log entry is added when client confirmed that this fix is working.

I have been on receiving end of similar situation, when RC version have some fix/change for my problem, but nothing is in change log.

There are many repetitive requests for full and comprehensive documentation of changes made. Even though when RC or stable version is released everytime it contains undocumented changes. They are easter eggs that we are revealing in such type of contest named "who crashes first can downgrade back". Therefore knowing all changes in advance would not be so funny.

"full and comprehensive documentation of changes made" doesn't exist.

I'm sorry, but is ether "full" or "comprehensive", It can be both only for developers that write that code.
RouterOS in fact is Linux, so have you tried to track and follow Linux Kernel changes? full -yes! comprehensive - hell no!
Also you can't show all changes to customers, especially in case those are related to new/unannounced hardware or feature.

Just by eliminating any "kamikaze" upgrades, and testing version before applying to production network - 80% forum problems would be solved in the root.

"
Just by eliminating any "kamikaze" upgrades, and testing version before applying to production network - 80% forum problems would be solved in the root.

I think 20% would be more certain.

RouterOS in fact is Linux, so have you tried to track and follow Linux Kernel changes? full -yes! comprehensive - hell no!

I'm not 100% sure where you are going with this line of argumentation. Are you saying that the Linux kernel, a very high-profile open source project, doesn't publish a comprehensive summary of all changes made, so if a project like that can't manage to do it, how can we expect MikroTik to do so? (In other words, you are saying an expectation of a comprehensive change summary with every release is unreasonable.)

Or are you saying that many of the problems that RouterOS users experience are in fact not the fault of the MikroTik developers, but can be directly attributed to changes being made upstream by the Linux kernel developers? If you meant the latter, I'm pretty sure you are wrong, since from what I can tell, MikroTik sticks with a particular version of the kernel source throughout the entirety of a single RouterOS major version. RouterOS 5.x was kernel 2.6.35, from 5.0 all the way through to 5.26. RouterOS 6.x is kernel 3.3.5, all the way from 6.0 to 6.22. MikroTik devs might be making changes to the kernel source tree, either via self-developed changes or by applying patches developed by others (backports of bug fixes from later kernels, maybe), but they aren't switching kernel versions in the middle of a release cycle, so although perhaps bugs that were introduced between 5.26 and 6.0beta1 can be blamed partly on the new kernel, regressions within the 6.x series cannot.

Also you can't show all changes to customers, especially in case those are related to new/unannounced hardware or feature.

Okay, support for new hardware, sure. I'll give you that one. But new features, I would argue, should not be shipping on existing stable release branches, especially if you have to make changes at the core to support the new feature that could cause regressions to occur in other already existing parts of the system.

For example, in my opinion, the big PPP changes made between 6.7 and 6.8 should not have been shipped with 6.8. It could have been released as a separate package, like 'ppp-test', for those who wanted to try it and help test it, or it could have waited until 7.0beta1. The same thing goes for the change from stores to disks in 6.20. There is almost no good reason to ship that sweeping of a change in 6.x and not wait until 7.x. The only exception I can even think of that I would be willing to allow for is if the existing 'stores' feature were broken in some fundamental way that was actively impacting users, and it was determined that the problem cannot be fixed with anything other than a from-the-ground-up rewrite. Even then, I'd say that's really pushing it.

Most of the people who are asking for a comprehensive summary of changes from release to release really aren't even talking about the kinds of things you bring up, though. Often MikroTik will make a change themselves to a version that they know about and that was done in direct response to a ticket that a user opened with them about a bug, and the fact that this bug was fixed will not make it into the release notes. That is the kind of thing that people are talking about here.

-- Nathan

I think by comprehensive, macgaiver meant "easy to understand". these changes are often "optimized code to take up less space". so what does that tell you? nothing. but if a bug will arise from this optimisation, you will ask "how can there be a bug, if there was no change in the changelog that something was modified"

I think by comprehensive, macgaiver meant "easy to understand". these changes are often "optimized code to take up less space". so what does that tell you? nothing. but if a bug will arise from this optimisation, you will ask "how can there be a bug, if there was no change in the changelog that something was modified"

Yes, that makes sense. I don't think that anybody (well, at least anybody who is reasonable) is asking for a report on every line of code that was modified. For that, you would have to publish unified diffs.

But 2 thoughts come to mind:

1) Even the summaries are never complete. Here is a good example: there was a bug in CAPsMAN up until 6.16 where the signal level thresholds in the access list had no effect. Uldis posted on the forum here (a day before 6.15 was released) saying that MikroTik had reproduced the problem and that it would be fixed in a future version. 6.15 didn't fix it, 6.16 did, but it is not mentioned in the release notes at all. I had to figure out which version contained the fix by trial and error (I needed an older version of RouterOS that didn't contain a bug I am working with support on resolving now, but that did contain the fix to this particular bug, so I had to start at 6.11 and keep upgrading one version at a time until the bug was gone because you didn't publish the fix in the release notes).

2) This is a different topic, but why would developers be optimizing code that already is working if there is a risk that the optimization could break something or introduce a new bug? Those kinds of changes, even if they do not add functionality, should be reserved for beta releases, IMO.

-- Nathan