Community discussions

 
plisken
Forum Guru
Forum Guru
Topic Author
Posts: 2421
Joined: Sun May 15, 2011 12:24 am
Location: Belgium
Contact:

RouterOs 6.23rc1 changelog

Mon Nov 17, 2014 6:07 pm

@Mikrotik
I let you now that changelog not is complete.
Just date but nothing else more
 
rzirzi
Member
Member
Posts: 378
Joined: Mon Oct 09, 2006 2:33 pm

Re: RouterOs 6.23rc1 changelog

Tue Nov 18, 2014 5:47 pm

Be patient. It's normal that they don't know what changed at specified version ;)
 
w0lt
Member
Member
Posts: 484
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

Re: RouterOs 6.23rc1 changelog

Tue Nov 18, 2014 9:06 pm

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

Really? :shock:
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.
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "

Image
 
jarda
Forum Guru
Forum Guru
Posts: 7602
Joined: Mon Oct 22, 2012 4:46 pm

Re: RouterOs 6.23rc1 changelog

Tue Nov 18, 2014 10:09 pm

Because just that. We see this everytime. That's how it goes here.
 
guipoletto
Frequent Visitor
Frequent Visitor
Posts: 92
Joined: Mon Sep 19, 2011 5:31 am

Re: RouterOs 6.23rc1 changelog

Thu Nov 20, 2014 4:06 am

Plausible deniability?
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1721
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

Re: RouterOs 6.23rc1 changelog

Thu Nov 20, 2014 8:39 am

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.
With great knowledge comes great responsibility, because of ability to recognize id... incompetent people much faster.
 
jarda
Forum Guru
Forum Guru
Posts: 7602
Joined: Mon Oct 22, 2012 4:46 pm

Re: RouterOs 6.23rc1 changelog

Thu Nov 20, 2014 8:49 am

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.
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1721
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

Re: RouterOs 6.23rc1 changelog

Thu Nov 20, 2014 11:47 am

"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.
With great knowledge comes great responsibility, because of ability to recognize id... incompetent people much faster.
 
visalink
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Oct 03, 2013 1:42 am

Re: RouterOs 6.23rc1 changelog

Fri Nov 21, 2014 3:17 am

"
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.
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 798
Joined: Tue Aug 03, 2004 9:01 am

Re: RouterOs 6.23rc1 changelog

Fri Nov 21, 2014 8:49 am

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
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24205
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: RouterOs 6.23rc1 changelog

Fri Nov 21, 2014 9:07 am

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"
No answer to your question? How to write posts
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 798
Joined: Tue Aug 03, 2004 9:01 am

Re: RouterOs 6.23rc1 changelog

Fri Nov 21, 2014 9:25 am

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

Who is online

Users browsing this forum: No registered users and 115 guests