LTS in Linux and Asterisk are major releases, not minor ones.

I own and operate a small software company. While I don’t know everything, I do have experience related to this subject. The new approach MikroTik has taken is the right approach conceptually speaking. I have been extremely scared to update to new versions of the firmware and look forward to this new release schedule.

Since MikroTik's goal is to instill confidence to the technical community, I think the best way to do that would be to offer a permanent bug fix branch. Since we can't change the past, going forward, MikroTik could do something similar to this:

Maintain two branches: FEATURE and BUG

RouterOS version 7.0.0 -- 7 is the MAJOR version and represents the beginning of time.
RouterOS version 7.1.0 -- the next digit is the branch identifier
even number for FEATURE, odd number for BUG branch. BUGP branches are frozen in time, forever.

Let's walk through time to see how this will play out.

7.0.1 -- FEATURE branch, first update. A new Wifi package was added, that's nice.

7.1.1 -- BUGP release, a bug was found in 7.1.0 and corrected. Notice, this version does not (never will) have the new Wifi package.

7.1.2 -- BUGP release, a small bug was fixed. This version is becoming very stable.

7.2.0 -- FEATURE release, a new one too. MikroTik wanted to release a version with the Wifi package that was based on 7.1.2. They also added a new DNS package.

7.3.1 -- BUG release (not P branch), that new DNS package turned out to be buggy. Oops. They fixed it.

7.1.3 -- BUGP release, this version is rock stable! Only a tiny bug fixed, nothing new added.

--two years later

The FEATURE branch is now at 7.6.2 and has many features. The BUGP branch is at 7.1.15 and is so stable some people say that MikroTik means "stability" in Esperanto. MikroTik killed off the 7.4 branch after they fixed it with 7.5 which eventually turned into 7.6. Notice how the Version 7.1 still lives on and only changes when necessary.

Notice that there is a permanent BUGP release, and Mikrotik can choose (at their discretion) to have multiple BUG versions for each of their FEATURE releases based on how much time and resources they have. The benefit is that for those of us whose reputations are on the line, we have a BUGP release we can count on.

MikroTik can add and fix things all they want. Internally at MikroTik, they will probably be maintaining three branches of their firmware: The permanent BUGP release, the new FEATURE releases, and random BUG releases for the each of the new feature releases. This means MikroTik can choose to kill off random FEATURE branches as they merge in BUG releases.

I have installed 6.30.4 on a RB750. I did a factory reset. Port flapping occurs on all the LAN ports when connected. I downgraded to 6.29.1. No port flapping occurs. (Port flapping also occurs on 6.31, that is noted in the release notes for 6.32rc6, but it implies that the problem was introduced in 6.31. The problem seems to have been introduced in 6.30 and is still present in 6.30.4.) By the way, the port flapping is fixed in 6.32RC6, but if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

...if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

It's a standard default config, why you say "very strange"?

...if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

It's a standard default config, why you say "very strange"?

I say "very strange" because in all other releases setting to default configuration on this router sets the router up as a SOHO router with a firewall, WAN port on eth1 (with DHCP client), and LAN ports with DHCP server on eth2-5.

6.29 and 6.30.2 had major problems for me. 4 days ago I upgraded about 10 towers (some bridged, some routed, some a bit of both to 6.30.4 as a last ditch attempt before facing the prospect of dropping them back to 6.7.. So far so good.

6.30 should be equivalent to LTS.
Having a list of "known" bugs, "known" missing features and "known" workarounds is OK.
Upgrading a stable version with reasonable confidence that no new bugs will be introduced is essential.

Crossing fingers because there's a good chance that the latest "latest Stable version" (sic) new features and bug fixes have introduced lots of new bugs is not good in many environments.


To prevent a nightmare of multiple versions for the developers/testers, might I suggest something like:-
A new LTS version every 3 months (development being so fast at Mikrotik !).
Maintenance/bug fixing of the previous LTS for up to additional 3 months (so 6 months "support" in total).
Maintenance/bug fixing of non LTS versions for 1 month.
e.g.In 10 months time, we'd be able to choose something like.
6.30.32 - LTS. Unchanged for 4 months.
6.40.38 - LTS. Unchanged for 1 month.
6.60.23 - LTS. Previous so bugfix support for next 2 months.
6.70.7 - LTS. Released previous month.
6.71.3 - previous stable version plus 2 bugfixes.
6.72 - current stable version

That is hardly LTS. LTS is supposed to last years.

I don't think it makes much sense for RouterOS.

I think, the mentioned LTS approach like Ubuntu, or better Asterisk (they had the same Problem as Mikrotik before), is the best one.

An additional option is to do feature upgrades with packages as it is done with wireless package. So if you need top end wireless features you can select the newer package and take the risk.

Since all packages needs to have same version number that sounds impossible to me. Or you get bugfix versions on packages as well, makes it even more complicated imho. Good idea but after some thinking maybe better not.....

1st priority for administrator is stability
2nd priority is to have best network with latest features.

After reading previous posts and falling in some 'traps' my self I produced following structure. Its basically mentioned by some already and imho it combines most suggestions in one working scheme.



For stability highest version will be one with bugfixes without any new features compared to 6.xx ("0" version).
Only after some time (2 months sounds reasonable) that version that after its last bugfix shows no more new mayor bugs can bear the title "current" because its been declared 'stable'

New version that adds new features are 'rc' versions until it has proven to have no new bugs. (Same procedure as with stable version.

So:

3.30 is always "rc" (3.29 or older is "stable"); Users are picking it up because it brings new features shown in log, hence we call it 3.30rc (ALWAYS!); ==>> bugs come up ==>> bug fix is made ==>> 3.30bf1 ==>> 3.30bf2 etc. until for 2 months no more new bugs surface ==>>3.30bf5 is declared "current" (maybe some selected users can vote?) and will bear name 3.30S+ (=Stable+support)
[a "bf" version is therefore always a 'bugfix' for a "rc" version. Only after 60 days without buf fixes a rc version evolved through its "bf" versions into a "S" version, stable. Only than it can become "current" version on the server for regular downloads]

At the same time other development can be made, but have to be put in new version 3.31 that will be called 3.31rc
Same process as 3.30 will be followed and one day it can be called "current" and bear name 3.31S+

Only when 3.31S+ is there it can take over the title "Current" from 3.30. Because only now everybody should be able to install it without problems.
If you are still waiting for new features, probably 3.31rc and 3.32rc are out but it didn't survive 60 days without bugfixes yet....


Scheme:

3.30rc ==> 3.30bf1 ==> 3.30bf2 ==> 3.30bf3 ==>3.30bf4==60 days=>3.30S ==> "Current" ==> "S+"
3.31rc ==>3.31bf1==>3.31bf2 ==> 3.31bf3 ==>3.31bf4==60 days=>3.31S ==> "Current" ==> "S+"
3.32rc ==>3.32bf1==>3.32bf2 ==> 3.32bf3 ==>3.32bf4==60 days=>3.32S ==> "Current"
etc.

Indeed we now might have several 'lines' of initial "rc" versions with their "bf" versions. Each line only becomes "S+" after 60 days without new bugs and only the latest line (highest number) with "S+" can be made "Current"

Now its also important the website states for each "rc" clearly what new features are compared to previous version.
Make a graph that clearly shows what features are in what version. A simple spreadsheet might do with older versions slowly fading away in time when more and more new versions are introduced.
(This would also make it more easy to troubleshoot some issues by the user if he enters in a problem after some versions were introduced in his routers. Or some don't like new features and want to stick to latest version without some specific feature.)

Than for each bugfix version a changelog should be maintained.

Off course the website should have some basic explanation saying:

1. "Current" version is latest 60 day stable version after some bug fixes. No more new important bugs found..
2. "S+" is a versions proven to be stable and MT renders support but lesser features compared to "Current"
3. "RC" versions are versions that have new features compared to "Current" but is not grant the "Current" status since its younger than 60 days and bugs might still submerge.
4. Older versions fading away in time will loose the "+" when MT is not giving support any longer. Probably only the latest family version might carry the "S+" sign for years untill its really outdated.. (any body still using 3.xx??)

Auto update from the router (winbox, telnet, script etc.) should never, NEVER be a more recent version than the "Current". Only this version is a version that is around for at least 60 days after the last important bug fix for that line. So only this version is safe to use for ALL! No more mistakes will be made now......

What about 'small' non destructive bugs that might come up in the 60 days period?
These bugs are to be weighted by MT to declare them of lesser importance and should be fixed in a new rc version (with higher number.) The moment they decide to fixed into a new bugfix version of that specific line the 60 days counter should start counting again for that line.....
They will have to make that decision and there will always be discussion on it by the ones affected.




I hope in the end we will see a proper system established. On the moment its chaos. I run now 3.27's, 3.30's, 3.31's, 3.30.2's and 3.30.4's on my network and am still surprised at times that some boards go down after running fine for weeks without an issue..... and I need some new functions at time.....
Just replaced the 3.30.2 on the 2nd NetMetal that ran for 2 weeks without any hickup to 3.30.4 because it suddenly stopped passing traffic over a bridge port..... I thought 3.30.2 was pretty stable...

I think, the mentioned LTS approach like Ubuntu, or better Asterisk (they had the same Problem as Mikrotik before), is the best one.

An additional option is to do feature upgrades with packages as it is done with wireless package. So if you need top end wireless features you can select the newer package and take the risk.

Since all packages needs to have same version number that sounds impossible to me. Or you get bugfix versions on packages as well, makes it even more complicated imho. Good idea but after some thinking maybe better not.....

1st priority for administrator is stability
2nd priority is to have best network with latest features.

After reading previous posts and falling in some 'traps' my self I produced following structure. Its basically mentioned by some already and imho it combines most suggestions in one working scheme.



For stability highest version will be one with bugfixes without any new features compared to 6.xx ("0" version).
Only after some time (2 months sounds reasonable) that version that after its last bugfix shows no more new mayor bugs can bear the title "current" because its been declared 'stable'

New version that adds new features are 'rc' versions until it has proven to have no new bugs. (Same procedure as with stable version.

So:

3.30 is always "rc" (3.29 or older is "stable"); Users are picking it up because it brings new features shown in log, hence we call it 3.30rc (ALWAYS!); ==>> bugs come up ==>> bug fix is made ==>> 3.30bf1 ==>> 3.30bf2 etc. until for 2 months no more new bugs surface ==>>3.30bf5 is declared "current" (maybe some selected users can vote?) and will bear name 3.30S+ (=Stable+support)
[a "bf" version is therefore always a 'bugfix' for a "rc" version. Only after 60 days without buf fixes a rc version evolved through its "bf" versions into a "S" version, stable. Only than it can become "current" version on the server for regular downloads]

At the same time other development can be made, but have to be put in new version 3.31 that will be called 3.31rc
Same process as 3.30 will be followed and one day it can be called "current" and bear name 3.31S+

Only when 3.31S+ is there it can take over the title "Current" from 3.30. Because only now everybody should be able to install it without problems.
If you are still waiting for new features, probably 3.31rc and 3.32rc are out but it didn't survive 60 days without bugfixes yet....


Scheme:

3.30rc ==> 3.30bf1 ==> 3.30bf2 ==> 3.30bf3 ==>3.30bf4==60 days=>3.30S ==> "Current" ==> "S+"
3.31rc ==>3.31bf1==>3.31bf2 ==> 3.31bf3 ==>3.31bf4==60 days=>3.31S ==> "Current" ==> "S+"
3.32rc ==>3.32bf1==>3.32bf2 ==> 3.32bf3 ==>3.32bf4==60 days=>3.32S ==> "Current"
etc.

Indeed we now might have several 'lines' of initial "rc" versions with their "bf" versions. Each line only becomes "S+" after 60 days without new bugs and only the latest line (highest number) with "S+" can be made "Current"

Now its also important the website states for each "rc" clearly what new features are compared to previous version.
Make a graph that clearly shows what features are in what version. A simple spreadsheet might do with older versions slowly fading away in time when more and more new versions are introduced.
(This would also make it more easy to troubleshoot some issues by the user if he enters in a problem after some versions were introduced in his routers. Or some don't like new features and want to stick to latest version without some specific feature.)

Than for each bugfix version a changelog should be maintained.

Off course the website should have some basic explanation saying:

1. "Current" version is latest 60 day stable version after some bug fixes. No more new important bugs found..
2. "S+" is a versions proven to be stable and MT renders support but lesser features compared to "Current"
3. "RC" versions are versions that have new features compared to "Current" but is not grant the "Current" status since its younger than 60 days and bugs might still submerge.
4. Older versions fading away in time will loose the "+" when MT is not giving support any longer. Probably only the latest family version might carry the "S+" sign for years untill its really outdated.. (any body still using 3.xx??)

Auto update from the router (winbox, telnet, script etc.) should never, NEVER be a more recent version than the "Current". Only this version is a version that is around for at least 60 days after the last important bug fix for that line. So only this version is safe to use for ALL! No more mistakes will be made now......

What about 'small' non destructive bugs that might come up in the 60 days period?
These bugs are to be weighted by MT to declare them of lesser importance and should be fixed in a new rc version (with higher number.) The moment they decide to fixed into a new bugfix version of that specific line the 60 days counter should start counting again for that line.....
They will have to make that decision and there will always be discussion on it by the ones affected.




I hope in the end we will see a proper system established. On the moment its chaos. I run now 3.27's, 3.30's, 3.31's, 3.30.2's and 3.30.4's on my network and am still surprised at times that some boards go down after running fine for weeks without an issue..... and I need some new functions at time.....
Just replaced the 3.30.2 on the 2nd NetMetal that ran for 2 weeks without any hickup to 3.30.4 because it suddenly stopped passing traffic over a bridge port..... I thought 3.30.2 was pretty stable...

We've 6.30 running everywhere now without a problem. This is our current stable.

We have 6.30.4 almost everywhere, only some 6.27 on far devices.
Both very stable IMHO

That is hardly LTS. LTS is supposed to last years.

I don't think it makes much sense for RouterOS.

It's all relative. 6 months of supporting a stable release is much longer than the current "install and hope" scenario.

The newer the version, the more risk. If you don't want/need to run bleeding edge (I still run 6.7 on many devices), you currently have to take an educated guess (usually by spending hours on this form to find feedback) as to which release is the most stable using certain features in certain scenarios.

It would be much simpler to have some LTS versions with a known list of features/bugs and make the choice of which release to use based on the features you require. As for the syntax of RouterOS version numbers and release schedule of the invariably buggy "latest stable versions", I don't really give a monkeys.

Oh..6.30.4 - still working

We've 6.30 running everywhere now without a problem. This is our current stable.

The fact bug fixes are already at 6.30.4 means it is not a stable version. Maybe for you but not for lots of others.

What a single user's experiences are with certain version is not relevant. Only if for some time no new complaints or failures are shown by several users on different platforms and with different configurations a version can be called "stable".

I have had now several units that after weeks of running with 6.30 still stopped passing traffic. Where under 6.27 same boards in same setup worked flawless for at least half a year.....

That is hardly LTS. LTS is supposed to last years.

I don't think it makes much sense for RouterOS.

It's all relative. 6 months of supporting a stable release is much longer than the current "install and hope" scenario.

The newer the version, the more risk. If you don't want/need to run bleeding edge (I still run 6.7 on many devices), you currently have to take an educated guess (usually by spending hours on this form to find feedback) as to which release is the most stable using certain features in certain scenarios.

It would be much simpler to have some LTS versions with a known list of features/bugs and make the choice of which release to use based on the features you require. As for the syntax of RouterOS version numbers and release schedule of the invariably buggy "latest stable versions", I don't really give a monkeys.

Oh..6.30.4 - still working

Yes, but a minor version that is maintained for 6 months is not really the same concept as an LTS.

For me, an LTS is not something that you need only for stability.

There is still a problem with connection bytes and connection rate when used together. I am using this feature from long time to divide the "heavy traffic" from "normal traffic". But since version 6.30, I think, it is not working anymore. The rule is something like:
The first rule does not capture traffic anymore, as result packets are not marked and queues in relation are not working.

My happiness was premature. The "CCP lost compression got out of sync" L2TP/IPSec VPN client bug is still present in this version, even when compression is disabled in the ppp profile.
The "dial on demand" option in SSTP VPN client still acts strange - connects and disconnects in cca 1 second pace.
Ticket #2015081866000551

Found a minor bug in 6.30.4, easy to duplicate.

Winbox 3rc12
RB1100AHx2

Control B does not work to bring up comments. Works fine on RB2011iL

Cheers

Found a minor bug in 6.30.4, easy to duplicate.

Winbox 3rc12
RB1100AHx2

Control B does not work to bring up comments. Works fine on RB2011iL

Cheers

Ctrl+M is the shortcut for comments...

Sorry, I fat fingered that : ) I meant control M doesn't work on the 1100AHx2.

You probably tried to CTRL-M a dynamic item. Works OK on static items on my 1100AHx2 (and this is how it should be....).

How does one install this version? I need the npk file, or? Where do I get it?

How does one install this version? I need the npk file, or? Where do I get it?

http://www.mikrotik.com/download
And select the version

How does one install this version? I need the npk file, or? Where do I get it?

http://www.mikrotik.com/download
And select the version

Thank you, newer seen that box before.

You probably tried to CTRL-M a dynamic item. Works OK on static items on my 1100AHx2 (and this is how it should be....).

No, I'm well aware of dynamic entries. I first noticed it while updating filter rules, then tried it on all kinds of entries. None worked on any of our 1100AHx2s. But like I mentioned, there was no problem with the 2011iL-wRMs.

Update - I rebooted the computer, and now it works as expected. That's bizzare.

On RB912UAG-5HPnD (used as AP and ethernet linked to Ubnt Airgrid M5) I've encountered ethernet negotiation issues with 6.30.4; after 1-2 days the link go down and the ubnt device say 'unplugged'.
Downgraded RB912 to 6.27 (with witch the board had worked well for months), now 3 days had passed and ethernet is still ok.

Just a guess ..maybe something related to (Interface/Ethernet/Status Tab) 'Last Link Up Time' and 'Link Downs' counters/functionality ?? (present on 6.30.x+ and not in 6.27)

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

+1000

Also +1000

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

+1000

Also +1000

I'm not sure, isn't that what we currently have with v6.30.4? Or you are asking for something else?

I have installed 6.30.4 on a RB750. I did a factory reset. Port flapping occurs on all the LAN ports when connected. I downgraded to 6.29.1. No port flapping occurs. (Port flapping also occurs on 6.31, that is noted in the release notes for 6.32rc6, but it implies that the problem was introduced in 6.31. The problem seems to have been introduced in 6.30 and is still present in 6.30.4.) By the way, the port flapping is fixed in 6.32RC6, but if you do a reset configuration with 6.32rc6, the configuration goes to a very strange config with no firewall or routing and the IP address of 192.168.88.1 configure only on eth1.

I had the same problem two days ago. After installation 6.32.1 everything is ok.

@normis; Imagine yourself; You are new to Mikrotik, just bought some routers to make some network. Like all software driven devices nowadays first thing you'd look for is if there is a new software/firmware on the manufacturers website. So you go to http://www.mikrotik.com and go to the download section were you'll find a "current" version. As newbee not knowing how the system works you download it, install it and 50% change you're in deep s*it then........ because "current" doesn't mean "stable" it means; "Lets hope this works...."

Or,
You are a network operator and know Mikrotik has regular updates on their software; so you spend some time to develop an automated upgrade system/script because manually that is just too much work. So you arranged the routers to regularly check the server to see if there is a new OS version and the router downloads it and installs it. Off course, the script only looks for the "current" version, yet again, next days you'll find out half your network went down the drain. Havoc everywhere.....

Or,
You are a long time forum member and user of Mikrotik and because of that you never trust new software releases immediately after they have been issued. So you wait and monitor the forum until you think the latest OS with some new features you'd like is stable enough to download. So, you start the auto upgrade script, or do it manually like a robot. In doing so after some upgrades you suddenly look at the upgraded boards and; "f*ck, they just put a new OS as current, I wasn't prepared for that! Let's hope it works...... fingers crossed!" and yes, after some hours (or immediately if you are lucky) boards start to crash....


These are just some examples why the "current" version that is given as default on the website or on the upgrade servers should be the last known stable one. If that is the one with several bugfixes, good. It means the bugs are fixed.

Although the word "current" can mean several things, the impression is created that it is a version that is recommended to use. And if it is recommended by the manufacturer to use it normally spoken means "it is stable". But not with Mikrotik, in Mikrotik it means " we hope it works, lets see how many people find issues so we can start correcting them...."

Hence my fellow forum users state

No. I would like a longer lasting Bugfix release without new features. Our network is no playground. Stability is number one feature.

It means that a "stable" version should be the preferred option on the website and upgrade servers by default.

Imho "current" should be skipped in terminology and start using the words "stable" for bug fixed versions and "New" for versions that are currently called "current". And then you can still have the "release candidates".

If Mikrotik maintains putting the label "current" on versions that are at times not by far matured, you'll find more and more frustrated users. I don't think that is what you are looking for?

[Another alternative label for the present "current" versions might be "play".... so if you want to play with your network go for it.... but if you don't like gambling, stay away from it...]

@normis
We need at least one 100% stable release of 6.xx, with no major bugs - and yes, 6.30.4 is the best at the moment .
Some new additional features in ROS are less important for us (speaking as an WISP network administrator).

Also, I agree with your new release policy except in one detail - please make the latest stable bugfix release default option for download/upgrade instead of the current one, it is safer option for most cases.
I think that way both of us will have less problems.
If someone really wants to test some new feature(s) then let them manually chose and download the latest current release.

One more advice, please please please keep your syntax coherent, don't ever change it for existing features, it gives us hell for automating tasks.

@WirelessRudy - 100% agree again

I'm not sure, isn't that what we currently have with v6.30.4? Or you are asking for something else?

No not asking for anything else, I like many other WISP's grade stability as number one and new features second

please make the latest stable bugfix release default option for download/upgrade instead of the current one,

We can't do that, because old versions know nothing of the chain system. They check the "current" and we can't change this without an upgrade.

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

While I agree with the development format but must voice concerns about RC, especially as they contain A+B and are not
thoroughly tested, should RC contain during installation a warning prompt that they are RC and be warned? "Do you want to install Yes/No"
Bugfix and Current don't need this warning prompt as I assume more thorough testing is done?

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

While I agree with the development format but must voice concerns about RC, especially as they contain A+B and are not
thoroughly tested, should RC contain during installation a warning prompt that they are RC and be warned? "Do you want to install Yes/No"
Bugfix and Current don't need this warning prompt as I assume more thorough testing is done?

Well, we have seen that actually "Current" does need same warning. How many of us gone wrong here, now and in the past?

There should be only one version for default downloads and that should be a "Stable" version. And that should be the only "current" version. Anything else is either 'development', 'release candidate' or 'EOS' (End of support).

And referring to normis his schedule; Like some proposed before, if certain version after some bugfixes becomes stable for some period, some weeks for instance, only than a version can become "Stable"

So although 6.30.4 is still a bugfix, maybe after two more weeks without any new surprises it could be renamed into 6.30.SR meaning Stable Release. Until that moment 6.29 or even 6.27 should be the "current" on the website. (This is due the transition we are in on the moment)

6.32 should still be a "rc" and 6.32.x will be bugfixes to the rc. Only if for some weeks no more bugs are found it can be renamed into 6.32.SR and become the default download option at that present to be labelled as "current". (Well; "Stable")

6.32 incorporates the new software channels so from 6.32 onwards any user has the option to start 'playing' with new releases and candidates etc. even from within the router's auto upgrade function. Indeed a good idea at least on the website to post a warning on any version that is not yet "Stable Release".

Only this way profesional users can build automated process to upgrade the system. Because only this way a "current" version is 99% guaranteed stable.

This is really the last time I nag about the procedure and propose some changes. Some might think I've got nothing else to do....

please make the latest stable bugfix release default option for download/upgrade instead of the current one,

We can't do that, because old versions know nothing of the chain system. They check the "current" and we can't change this without an upgrade.

You can use two coincident aliases ("current" for old ros and "stable" for newer ros) pointing to actual bugfix releases.
Then you start use a new alias (e.g. develop/new/cuttingedge/..) for actual current releases.

P.S. ..and, please, backport port flapping fixes on 6.30.5 ..on some board (like RB912 I still have to use 6.27)

Only this way profesional users can build automated process to upgrade the system. Because only this way a "current" version is 99% guaranteed stable.

I think I agree with many of the ideas expressed here (mainly: we need releases without bugs, maintened for a long time, even it is means that they lack new features).
But, one thing : you CANNOT blame Mikrotik if your automated update process failed because of new release coming-out at the wrong moment !

What I mean is : if you build automated process to upgrade many devices, you SHOULDN'T use the "simple" auto upgrade command that will one day install a version that you do not want.
First, you SHOULD test (intensively) one release, and once you have validated it on your test device*s*, you update your production devices farm.
And more importantly, in your script, you SHOULD do the upgrade by uploading manually the version that you have (tested+validated+) selected to the device. Basically :
=> scp routeros-mipsbe-6.30.4.npk admin@yourDevice:/
=> /system reboot

[But, one thing : you CANNOT blame Mikrotik if your automated update process failed because of new release coming-out at the wrong moment !

What I mean is : if you build automated process to upgrade many devices, you SHOULDN'T use the "simple" auto upgrade command that will one day install a version that you do not want.
First, you SHOULD test (intensively) one release, and once you have validated it on your test device*s*, you update your production devices farm.
And more importantly, in your script, you SHOULD do the upgrade by uploading manually the version that you have (tested+validated+) selected to the device. Basically :
=> scp routeros-mipsbe-6.30.4.npk admin@yourDevice:/
=> /system reboot

I agree. I don't have such automate process in use anyway. I only mirror what I saw happening with others on this forum. As you can see I am a long term member and I learned already long time ago that installing the "current" version on your production environment is asking for problems.

And yes, I do think you can blame Mikrotik if they put a new release out and call it "current" while it is not by far stable.
[You'll find in the manual several examples how to do it to make your life as operator 'easy'... well, until disaster strikes...]

If tomorrow Microsoft will issue a new Windows patch (that by the millions is manually or automatically downloaded and installed) and the next day they find it has serious new bugs, it will hit the mainstream news channels....
How would dare to blame the user?

No, Mikrotik should not, never and ever, put a version out as the preferred default one (because that is the "current" version) if it is not al least has seen thorough testing...

Of course Mikrotik should not publish buggy releases. Nobody will say "Mikrotik should put more bugs in RouterOS".
But there is also reality of software development, and even with great care, bugs can and will happen and nobody can avoid them at 100%.
So, the question is how to conciliate 2 things : having as-less-buggy-as-possible software (which requires testing before) and releasing new version with new features (which will certainly introduce new bugs).
Because, imagine if everybody use the "bugfix" releases, nobody would use the new releases and nobody will spot the (inevitable) bugs in those, and the new releases will never get bugfix. So, at the end, we stay **forever** with a bug-free release but with nothing new for decades

NB: you are comparing 2 really different things :

1. some professional network administrators that apply MANUALLY (or with script) updates to devices
2. and users (with no tech knowledge) that are subject to AUTOMATIC updates of their windows

Of course Mikrotik should not publish buggy releases. Nobody will say "Mikrotik should put more bugs in RouterOS".
But there is also reality of software development, and even with great care, bugs can and will happen and nobody can avoid them at 100%.
So, the question is how to conciliate 2 things : having as-less-buggy-as-possible software (which requires testing before) and releasing new version with new features (which will certainly introduce new bugs).
Because, imagine if everybody use the "bugfix" releases, nobody would use the new releases and nobody will spot the (inevitable) bugs in those, and the new releases will never get bugfix. So, at the end, we stay **forever** with a bug-free release but with nothing new for decades

Not everybody will use the "bugfix" release only. Only 'no tech knowledge' users and professional network admins will use these initially and for their production environment.

There will be still lots of users that like to play around with new options, features etc. or have been asking for them so they need to be tested and tried.

What I every time have to come back on; 'A' version presented on the website and upgrade servers as "current" has to, will be and should, be seen as a stable version that just works on any routerboard. There might be an occasional small bug left for a rare usage, but in general it should be sound and stable.
This version will be used in a first upgrade if you just bought a new device, weather you are a absolute mikrotik 'dummy' or an experienced operator. This version can be used in upgrading your network, by script or manually. This should be the 'current stable' version. No doubts on that version.... All you want is the latest OS that just works... nothing more.

The moment the experienced want more, or is looking for something specific, or just like to be an 'beta' or 'charlie' tester, he or she, can try a newer version. That newer version might solve his specific need, or just brings something newer, better even. But at a cost; there might still be some bugs.
Doesn't matter, I am sure anybody that want to try such version should be aware of the cost in trying something new that is not completely mature.

The bottom line is; Not making any choice should give you a stable version, that can be called "current" (Not my choice of wording.)
If you want to try something new, YOU should have to make the choice.

Now its just the other way around......

NB: you are comparing 2 really different things :

1. some professional network administrators that apply MANUALLY (or with script) updates to devices
2. and users (with no tech knowledge) that are subject to AUTOMATIC updates of their windows

I consider myself pretty professional, my existence depends on the money I make with my network, but still. Let me explain what happend to me once or twice;

I have almost 800 MT units. I'd like to follow upgrade versions to improve my network to the edge, but not at any cost.
So how is my behaviour (I am sure a lot will do the same):
When a new version is out I follow the forum for at least a week to see if there are any issues. I there are issues that I think might hurt my network, I don't touch it.
If I think that there are little issues or the issues are not having effect on my network because they ocurre on configs I don't use, I can try it.
I start usually with brand new client units that are to be used and get their pre-config.
If they work in the field for a while and I do more and more than I move to some lesser important units close to home or easy to fix.
If still it all looks to go fine I might start with one small PtMP client network. I manually start upgrading all CPE's, one by one.
Since I have about 800 units to go this is a process that can take some weeks.
So, after some days doing some PtMP networks I finally go for some of the bigger AP's. 30, 40 CPE's. So you develop a sort of habit in doing how you do it, manually.
What happened now a couple of times? Well, without any notificación the 'current' version was replaced by a newer "current" version. I took some upgrade before I actually noticed it! Specially because such new version initially worked fine.
But I found myself suddenly upgrading production units into a new release version that might not be that safe as I thought I was upgrading....... bugger... fingers crossed they'd stay alive.

Now this would not be an issue as long as you could take it for granted a "current" version is sound and safe. But just recently we, and MT, just saw a version released (6.31) that was obviously not safe at all. And its not the first time this happened!

If MT would have developed a much more conservative strategy in publishing versions as "current" this would never had happend. By not changing their policy such 'mistakes' are prone to happen again and again, until all confidence in MT ROS is gone.

And remember, confidence goes by horse, but only comes back on foot.....

Because, imagine if everybody use the "bugfix" releases, nobody would use the new releases and nobody will spot the (inevitable) bugs in those, and the new releases will never get bugfix. So, at the end, we stay **forever** with a bug-free release but with nothing new for decades

One can solve that dilemma by extensive in-house testing before releasing new code at the first place.
So instead of that, all of us (paying costumers) have to agree to be test subjects in ongoing and never-ending software development??? Well, I would rather not to be a test subject by default.

We can't do that, because old versions know nothing of the chain system. They check the "current" and we can't change this without an upgrade.

Today we have a Mikrotik RouterOS device asking Mikrotik software central "Hey dear Mikrotik server, I'm RouterOS device with software version x.yy, which is the best software for me to download and install?" and you want to tell me you can't change server's default answer to that question?

No it does not work that way. Like I said, it is the same file for the v6.32 and for v6.29. If we change the answer to "v6.30.4" then also v6.32 will not receive updates to v6.33

Fine if it cannot be changed for 6.33, but you can fix it in 6.33 for 6.34

6.32 Current looks for upper Current. It gets 6.33 unstable Current

6.33 Current looks for upper Current or Unstable, it gets 6.34 Unstable or 6.34.1 stable Current

6.34 Unstable looks for upper Current or Unstable, it gets 6.34.1 stable Current

6.34.1 looks for upper Current, it gets 6.34.3 stable Current (assuming 6.34.2 remains Unstable)

Please post any remaining issues you find in this 6.30.4 release! This is important, to make this version truly stable.

Yes, naming the versions is not easy.

At the moment we are still debating how this should work in the long term.
Right now:

bugfix = stable, only bug fixes are included, no risky new features (A)
current = latest version with new features and bug fixes also (A + B)
release candidate = nightly build, not much testing, release as soon as usable, includes A + B + C changes that are not thoroughly tested yet
development = alpha/beta of v7 when we release it (not yet available)

The important question is, should we replace 6.30.4 with 6.31.1 when we have important issues in v6.31, or ... if you wish v6.30.4 to be maintained for a while, how should we release important fixes for 6.31 ?

Normis,

I would love to see 6.30.x stay around for at least 6 months if not longer and only move to the next bugfix when it is incredibly stable. Many other network vendors will keep bugfix only versions around for a very long time so that there is a clear choice for stability vs. new features over a long period of time. Now that there is a separate version for new features, I believe there is much greater value in keeping the bugfix as stable as possible than trying to move too quickly to the next bugfix release.

I think realistically, you might only have 2-3 bugfix versions to increment fixes in every major release. Something like

6.1.x - Bugfix at the beginning of the major release
6.15.x - Bugfix towards the middle of the major release
6.30.x - Bugfix towards the end of the major release

Obviously not every bugfix would be spaced that neatly apart, but it illustrates the idea.

I applaud the effort at MikroTik to work on improving the software development model to meet the needs of the vast majority of customers. Well done!

check-gateway=arp is flakey. at least when there are 100,000+ routes. fails over the secondary routes even though arp entry still exists and connectivity to original gateway is never lost. switched to =ping and works fine. supout sent.

No it does not work that way. Like I said, it is the same file for the v6.32 and for v6.29. If we change the answer to "v6.30.4" then also v6.32 will not receive updates to v6.33

And this is great! It should not be possible to automatically upgrade to the unstable version. If you want upgrade to unstable version - do it manualy.

No, if you are on the unstable stream, it should be possible to just click to get the next one.

I don't want to manually upgrade anymore.

However, a confirmation dialog would be welcome.

No, if you are on the unstable stream, it should be possible to just click to get the next one.

I don't want to manually upgrade anymore.

Well, as long as MT regularly put unstable versions as "current" than don't complain next time you'll find yourself automatically installed disaster on your network......

[Or you make a new upgrade script that only installs latest bugs fixed versions. Now that is possible too. But then it won't make a lot of sense to have a script, because once the bugs are fixed that version won't see any new coming anymore..

Yet again it proves why MT should get rid of "current" and use "stable" as the default version. Than it can follow the upgrade's timeline even if it goes to higher family version. As long as they make sure it is a 99% safe version automated processes can be used again. Now it's more like Russian Roulette......]

There seems to be a serious memory leak in this release that's triggered by viewing ip/firewall/connections in webfig. Once you bring up that page, available memory starts dropping and doesn't stop until you stop the www service. Exiting the browser alone doesn't help. It took my RB912 with 64mb memory only 3 minutes to go from 32mb avail to 2mb avail and a watchdog reboot. This is with about 500-700 connections in the table.

Support ticket created with supout.rif

Is 6.30.5 on the roadmap?

There seems to be a serious memory leak in this release that's triggered by viewing ip/firewall/connections in webfig. Once you bring up that page, available memory starts dropping and doesn't stop until you stop the www service. Exiting the browser alone doesn't help. It took my RB912 with 64mb memory only 3 minutes to go from 32mb avail to 2mb avail and a watchdog reboot. This is with about 500-700 connections in the table.

Support ticket created with supout.rif

I am unable to repeat this behavior on any of my routers here. I can leave this page open, but Free Memory stays solid and does not change. Please tell me the number of your support ticket, so I can check the status.

Is 6.30.5 on the roadmap?

Do you have any issues that we need to fix?

I have a problem to add ipv6 pool in From Pool field when i add ::/64 ipv6 Addresses.
I make a ipv6-pool in DHCPv6 client but this pool cant display at From Pool filed when i add ::/64 ipv6 Addresses.
When i load a backup from previous ROS, all work ok.
When i make reset configure add configure the router from beginning, i have the above problem.
In addition i have always connect/disconnect when i make pppoe client connections with ipv6 enable.
With previous backup file i dont have the same problem.
The configuration is exactly same.
The only different is I make reset configuration.
I have CRS109-8G-1S-2HnD-IN and the old board is RB951G-2HnD.
The problem is the same with this:
http://forum.mikrotik.com/viewtopic.php?t=61976

There seems to be a serious memory leak in this release that's triggered by viewing ip/firewall/connections in webfig. Once you bring up that page, available memory starts dropping and doesn't stop until you stop the www service. Exiting the browser alone doesn't help. It took my RB912 with 64mb memory only 3 minutes to go from 32mb avail to 2mb avail and a watchdog reboot. This is with about 500-700 connections in the table.

Support ticket created with supout.rif

I am unable to repeat this behavior on any of my routers here. I can leave this page open, but Free Memory stays solid and does not change. Please tell me the number of your support ticket, so I can check the status.

The ticket was 2015091366000031 and I got a response that the fix was in 6.32.1 and that does appear to be the case.

There is a bug in OSPF interfaces.
In Winbox when you add a comment to a ospf interface this goes down and stay for some seconds in the waiting state so run the dijkstra algoritm again and then it return in running state.