*) nv2 - fixed kernel failure with frame size accounting;
What problem was this? Did it happen on each nv2 running radio? I had some backhauls stalling after weeks of running, could this have to do with it?
Same story happens again: 6.32.2 [current] was pretty stable after being around for some weeks without too many new comments or disasters.
This morning found a client that still wasn’t upgraded to 6.32.2 so started the auto upgrade script and AGAIN to my surprise a new ‘current’ version (6.32.3) is installed. Do you guys never learn? DON’T call it “Current” and DON’T make it default download option.
Now I can only hope its a good one, not a new disaster in the make… (and its only a single client… pff)
This morning found a client that still wasn’t upgraded to 6.32.2 so started the auto upgrade script and AGAIN to my surprise a new ‘current’ version (6.32.3) is installed. Do you guys never learn? DON’T call it “Current” and DON’T make it default download option.
I never use(d) auto upgrade feature. I always upload the desired image manually. I really don’t know why to use the autoupgrade feature.
And if we want to upgrade many radios we use scripts which upload selected image and do all the dirty work (upgrading routerBOOT enabling th eproper wireless package, checking that the settings are really ok, etc)…
I’ll guess indeed I have to setup this work around…
I still think the word “Current” is not right. It should be “new” or “latest”.
“Current” to many people means the ‘going’ one, so the one that is good, safe, no surprises and recommended.
Its the preferred one to download and install.
This version is ‘new’ so only time will tell if any of the words “good”, “safe”, “no surprises” are covering the cargo…
Only after some weeks we can decide this is the preferred version. Its proven too many times things can go disastrous if a ‘current’ version is used as ‘recommended’ upgrade…
This is the last I’m saying about this topic. It seems you guys won’t change anyway…
*) nv2 - fixed kernel failure with frame size accounting;
What problem was this? Did it happen on each nv2 running radio? I had some backhauls stalling after weeks of running, could this have to do with it?
Any info on this?
Like I said, I had some NetMetals stop passing traffic after weeks of running normally. Can it be it was this bug stopping it?
If so I need to upgrade. If not, I might as well wait to have this version see survive the next weeks…
x.yy.zz
x - main version
yy - iteration of new feature set
zz - iteration of bug fixes for that feature set
It looks like MT is steadily moving v6.32.x version towards a good bug-fix version, by additionally proving it in Current channel, while 6.33 is under construction. You can’t just simply put a new version in bugfix channel, it need to be higher than usual quality to become a bugfix version.
Sorry, but I did not understand your versioning strategy at all
I know there was an thread to discuss, but may be you could give again an short explanation ?
What is the difference to set the version to 6.32.3 or 6.33.0, actual my unterstanding was that :
6.32.3 is a new release of 6.32.2 which contain bug fixes (last counter for bugfixes)
6.33.0 is a new release which contain new feautres (may be bug fixes) (middle counter for new features)
But you wrote can ‘include new features’, what is correct for 6.32.0 and 6.33.0 but not for 6.32.3 or i’m wrong ?
When do you decide to set the middle counter and when set the last counter ?
btw..
What ufm is asking for, and I’m too is : In 6.23.3 are a lot of buges fixed, may be some of that still in 6.30.x and should also fixed what lead into 6.30.5 ?
How can that be? You yourself write that “yy” means new feature set where “zz” means bug fixes for that feature set.
Now MT comes with a new “zz” version but instead of bug fixes it also has several ‘new’ features. In your wording increasing “zz” means only bug fixes. Increasing “yy” means new features.
We see now increased “zz” but also get new features jeopardizing this existing version. You must agree the new features should have an increase “yy” number…
So if you say it is logical/clear to you, you have a weird way of thinking. As the editor after you also states; it is not clear at all…
The bottom line is; 6.32.3 brings new features and/or bug fixes to 6.32.2. Just because of that simple fact it CANNOT be called a “current” version if “Current” in normal English means “the going one” and where any user should get the impression that a “going one” is a version that is safe, tested and recommended.
This is proven now many times it is just not the case… pffff
Screenshot 2015-10-20 14.08.05.png
Let’s open MikroTik.com download page.
current (channel) = new features + fixes*.
bugfix (channel) = fixes.
“new features+fixes” means latest tested features and fixes.
Let’s have a closer look at 6.32
At the moment current channel is 6.32.3, the previous current version was 6.32.2. There are only bugfixes added to 6.32.3
New features are (will be) added to 6.33, they are already present in 6.33rc (Release candidate channel).
Legacy - all versions prior 6.30 as they are not actively maintained. Stable - 6.30.yy which means 6.30 plus fix pack no. “yy” - the best WORKING version with known limitations Current - 6.32.xx - production version + fix/enhancement pack “xx” for all with stronger heart RC - Cutting edge version for testers, stuntmans and other barmy people
When RC becomes Current then we shift all names one level up.
The main question is if Current should receive new enhancements or stay only with fix packs to become Stable as soon as possible.
IMHO new features should go to RC and Current should receive only fix packs.
Ok, now it seems to be clear; 6.32.3 is just a newer version for 6.32.2 with mainly bugfixes and maybe some new features.
That could have been answered on my first post.
Since you guys keep on calling it “Current” it means it is a 100% (well, 99% ) reliable version that everybody can download and install without putting his network or router to a risk of failure by newly introduced errors. Good.
WirelessRudy
I replied to the particular question in main thread.
I copy answer here, nv2 fix was added to fix router occasional reboots in the specific configuration.
