Comments about RouterOS release schedule

Thu Jun 25, 2015 3:11 pm

We plan to make sub-version releases that only contain fixes and no new features.

For example, we would release 6.30 with some new features in FastPath. Then, if some issues are found, we would make 6.30.1 with only fixes and no new functionality. When we add a new option or feature, we would make 6.31.

6.XX.Y - only bug fixes
6.XX - fixes and feature changes

We could even make several fix-only releases in a row, if needed.

The idea is that you can upgrade to a sub-point release without risking new bugs, that could come with new features being added.

As the v6 cycle is coming to an end, there is simply no other 'branch' to put new features in, as v7 is still too 'raw'. We could stop with the sub-point releases once v7 is mature enough for general use.

Any comments about this idea?

doush · Thu Jun 25, 2015 3:17 pm

Yes this is a very good idea. +1 from me.
We can have the fixes quickly without risking new bugs.

DLNoah · Thu Jun 25, 2015 3:31 pm

I would rather see the sub-point release pattern continue indefinitely.

If you want to limit only certain "feature releases" (e.g. 6.30) to long term support, so that you're not maintaining point releases for dozens of different versions, that's understandable. But the constant roulette of "will the new features break more than the bug fixes fix" makes upgrading a very costly process. Bug fix only release branches will greatly improve the reliability of RouterOS and make our lives as system administrators better.

G2Dolphin · Thu Jun 25, 2015 3:32 pm

Nice one, I'm voting "yes" too.

avenn · Thu Jun 25, 2015 3:36 pm

Nice one, I'm voting "yes" too.

Yes + 1000

kamillo · Thu Jun 25, 2015 3:52 pm

I like the idea

kivimart · Thu Jun 25, 2015 4:14 pm

+1

Skickat från min HTC One via Tapatalk

Thu Jun 25, 2015 5:01 pm

+1
I vote for better bug tracking...anonymous access to http://bugs.mikrotik-routeros.com/view_all_bug_page.php shows almost no interest in resolving bugs.
It will help zilion times if there will be examples what and why was repaired instead of simple "*) pptp - fixed ~encryption got out of sync~ problem;"

Thu Jun 25, 2015 5:04 pm

+1
I vote for better bug tracking...anonymous access to http://bugs.mikrotik-routeros.com/view_all_bug_page.php shows almost no interest in resolving bugs.
It will help zilion times if there will be examples what and why was repaired instead of simple "*) pptp - fixed ~encryption got out of sync~ problem;"

you do know that that is not a MikroTik site, right ?

Thu Jun 25, 2015 5:12 pm

I know...but is the only attempt to manage it...even on this forum there was thread with it http://forum.mikrotik.com/viewtopic.php?t=78816

Why you do not have such tool ? I am all the time amazed with quality of changes tracking in SQLite http://www.sqlite.org/src/timeline

planetcoop · Thu Jun 25, 2015 5:14 pm

Not to take away from what normis has said about it not being a Mikrotik official site, but they are only tracking 54 bugs? That includes code all the way back in 5.x routeros and several listed under RC that was never meant for public consumption. I have found my share of things that don't work from time to time but within a version it generally gets fixed. +1 for Mikrotik giving us so many new features and keeping the network up. Cisco this past year has had so many bugs we quit counting...

Thu Jun 25, 2015 5:21 pm

... but they are only tracking 54 bugs..

It was example...anything is better than nothing....nice try without success
How they could track bugs if they do not know what was changed ?
How anyone except Mikrotik could manage such bugtracking system ?

marrold · Thu Jun 25, 2015 5:34 pm

Thu Jun 25, 2015 5:51 pm

This sounds like a fantastic idea so long as Mikrotik does not get bogged down in version management where a bug was fixed in 6.29.04 but that same bug gets re-introduced in 6.30 because the fix didn't get pushed up into the master code (or however version management is done).

planetcoop · Thu Jun 25, 2015 6:01 pm

ZeroByte, that is the issue that al vendors face. I saw two bugs in the past year where they were brought back on accident but Mikrotik was very fast to fix them.

BartoszP, I think the sqlite page looks neat with the tracking and linking of issues.

paoloaga · Thu Jun 25, 2015 8:09 pm

It's a great idea and I would like to see it applied also to v7 and beyond!

vortex · Thu Jun 25, 2015 8:37 pm

It seems you took notice of the request I made in some thread for feature and maintenance streams. Thanks, I think this is a win-win.

JAza · Thu Jun 25, 2015 9:39 pm

Absolutely positively +100!

This type of branching is standard in many software developments and should be kept for v7 and beyond. I think this will go a long way toward addressing many users' fear of updating to latest point releases. One of the first advices I was given on 'tik and give to others is "they're great. Just don't be the first one installing new releases and even stay a point or two behind and you'll be fine".

I think it's a great idea who's time has definitely come. Thank you.

cheeze · Thu Jun 25, 2015 10:09 pm

I would be 100% on board with that change.

However, if I may make a request/observation as a user of Mikrotik products. Please instead of using programmers to add to 6.x feature releases....please move them to version 7 development. That way version 7 has more development power.

Please only have people bugfix 6.x after 6.30. I think we all would rather have a very stable 6.30 code with say....15 or 16 bug fix revisions added to it than have 6.35 with only 2 or 3 bug fixes on it. Extra features are nice, but bug fixes and working routers are FAR better. That way when version 7.x comes out the bugs in version 6 aren't re-introduced into version 7.

That way version 7 can have more features when it does release AND it will have fewer bugs as there are more developers/testers working on it.

Lastly, PLEASE PLEASE start allowing for older versions of code to be downloadable. Please oh please. This will help so much out. For both firmware and RouterOS.

honzam · Thu Jun 25, 2015 11:20 pm

YES!
+100

dgonzalezh · Fri Jun 26, 2015 12:26 am

+1. it's fine by me, I think it's a great way of keeping track of what you're using and what to expect from net ROS versions. And as you mention a wa for people to upgrade according to their needs, for instance "6.30.3, Ok, a must for my production router" or "6.31, this will go into my lab's CRS to check what these guys are up to."

Count me in for testing.

Cheers.

We plan to make sub-version releases that only contain fixes and no new features.

For example, we would release 6.30 with some new features in FastPath. Then, if some issues are found, we would make 6.30.1 with only fixes and no new functionality. When we add a new option or feature, we would make 6.31.

6.XX.Y - only bug fixes
6.XX - fixes and feature changes

We could even make several fix-only releases in a row, if needed.

The idea is that you can upgrade to a sub-point release without risking new bugs, that could come with new features being added.

As the v6 cycle is coming to an end, there is simply no other 'branch' to put new features in, as v7 is still too 'raw'. We could stop with the sub-point releases once v7 is mature enough for general use.

Any comments about this idea?

Fri Jun 26, 2015 1:05 am

Great idea!

Fortinet changed to a similar model, and it has worked well for them.

sparky · Fri Jun 26, 2015 3:56 am

The idea is that you can upgrade to a sub-point release without risking new bugs

Yay!! +1000. Please do this and make it permanent. Stable software >> new features.

IntrusDave · Fri Jun 26, 2015 7:37 am

gotta love spammers. I'm sure that marketing strategy must be working well for them.

Anyway.

I would like to see the sub-point releases continue from this point forward. It would be helpful to know that a release is nothing but bug fixes, and that I would need a long test cycle. On that note, I would also like to have access to a list of known issues and fixes.

Fri Jun 26, 2015 9:15 am

Very good idea. I am totally for it under one condition: mikrotik will not release any new version until all open error reporting tickets are solved.

Then I suggest to mikrotik to keep all already solved error descriptions in test database as testing scenarios and make full test according to these scenarios before any new version or subversion is released to public. This will ensure that mikrotik will not stupidly reintroduce the same errors repetitively again and again.

Fri Jun 26, 2015 9:27 am

not release any new version until all open error reporting tickets are solved.

we have tickets that stay open for months, because either the customer can't provide any details about the issue, we can't repeat the issue, or simply there is some other reason the ticket can't be solved. There are issues that are fixable in a reasonable amount of time, and then there are those that can't be fixed quickly

petrisimo · Fri Jun 26, 2015 9:38 am

you know what normis,

PLEASE STOP BLAMING CUSTOMERS AND FIX BUGS. THIS IS MIKROTIK DUTY AND MIKROTIK COMMITMENT .

I am sick of that kind of attitude (it is customer who is wrong because it is using mikrotik product...)

Fri Jun 26, 2015 9:42 am

I am not writing about duties and commitments. I am asking you as a person, to be realistic. "FIX ALL BUGS"?

Bergante · Fri Jun 26, 2015 9:55 am

It's a very good policy that works very well for other projects, for example FreeBSD.

It is especially important for critical security updates that should be rolled out almost immediately. If it's too risky to install an update it won't be installed.

Also, this is good for Mikrotik, you can be more daring with new features in new releases by separating bug fixs from other changes.

Fri Jun 26, 2015 11:04 am

+1

NAB · Fri Jun 26, 2015 11:57 am

Back when I first started using ROS, MikroTik's attitude was "Our software is bug free and you should always be using the latest cutting edge version". The problem is that most people know that all software has bugs and MT's attitude made them a laughing stock in many circles. Over the years there has been an informal acceptance that ROS contains bugs and that maybe running the latest version wouldn't be the most sensible thing to do.

I am delighted to read Normis's post and I am really glad to see MT admit that their software has bugs just like any other piece of software. Hopefully this will go some way to making MikroTik a more credible solution for our customers.

The next step is to expand the changelog to give more information about the fixes and new features. The step after that is to open up the bug tracking database.

So, well done MikroTik. I just hope that this mindset continues into the 7.x release tree.

Fri Jun 26, 2015 12:21 pm

+1
Long awaited step. Next step is a testpattern every new version has to run through.

Fri Jun 26, 2015 12:35 pm

...we have tickets ...

The main problem is with the word "We". IMHO this "We" means MikroTik's staff.

"We" really should mean...no, no... have to mean "Users and Bugbasters@MikroTik".

The only way to solve many problems is digging forum for others' similar problems.....no...I would like to easy follow problems with bugtracker.

3bs · Fri Jun 26, 2015 1:06 pm

I would like to easy follow problems with bugtracker.

+1 needed bugtracker

Fri Jun 26, 2015 1:07 pm

BartoszP, do you have a problem that is not solved, and has been submitted to MikroTik?

Fri Jun 26, 2015 1:15 pm

OK, I think the topic has concluded with 100% agreement about versions.

About bug tracker, it has been discussed before: http://forum.mikrotik.com/viewtopic.php ... 00#p372600