*) ipsec - fix sockaddress buffer size on id generation for ipv6 address;
*) userman - refresh active sessions/users view dynamically;
*) package - added version tag and show everywhere alongside of version number;
*) rb493G - fixed reboot loop (introduced in 6.32);
*) wlan - improve single connection TCP performance for ac chipset with cm2 package;
*) defconf - fix default configuration for routers without wireless package;
*) mesh - fix router lock-up when interface is added/removed;
*) RB911/912 - fixed lock-up (introduced in 6.32).
Can I ask as a general rule what (basic) tests are done before releasing a RC ?
I mean a RC having reboot loop and lock-up ?
or are new issues like above just added to release checklist before releasing the RC.
I am repetitively asking for publishing quality assurance policies that mikrotik works according to, but I haven’t got any answer to it. I wonder if you will get info how they test the rc…
If we got a general checklist to what is tested before release, then we can decide how much we want to deploy into
our test network and a short time later maybe a section of the live network (?) and how much more testing maybe required before full deployment, in short we are trying to conduct a risk assessment to updates.
Very good. Does this help with mixed environment .ac AP and .n CPEs ?
Can you share some background information what is happening (packet reordering ? ack aggregation effect ?).
Usually in software development, there are 3 (or even more) different types of versions:
Beta → Unstable. New features are added in this phase
RC → Release Candidate. In this phase, no new features will be added. If testing is OK, it will be released
Stable → Released version
Most of the past releases, I would describe as “Beta”.
I have no idea how MikroTik can publish new RCs every day.
It is not about how we understand the naming. It is about our approach to the mikrotik software development life cycle. I would like to see newly released version that none will download and try just because none will want to risk the consequences.
Surely if you want to use the word ‘beta’ then ‘RC’ should be ‘alpha’?
Personally I think people should stop b*tching about the new release schedule, be greatful on the fact it’s better than the old system, and give it a few versions to bed in before they complain.
We have managed to reproduce issue with mangle rules disappearing. It will be fixed in upcoming 6.33rc versions.
As for rc version testing - Release Candidate is more likely to a nightly build. We will not do intensive testing before publishing these, only quick check if upgrade can be done and if most features work fine.
You are not forced to upgrade your router to rc version. Versions are released for those who has some problems on router and fix or possible fix is included in these packages. Basically rc is released for those who actually need it and for those who wants to do some testing and give us feedback.
New fixes:
*) RB532/RB564 - fixed no link after ethernet disable/enable;
*) firewall - do not lose firewall mangle rules on start-up (introduced in 6.32);
*) tile - fixed occasional deadlock on module unload;