RouterOS version 3.1 came out today just 9 days after version 3.0 was released.
Did we skip a minor version? I thought the natural progression for bug fixes from 3.0 was to 3.0.1…
not jumping directly to version 3.1.
What comes next? 3.2?
How does this jump in numbers affect future upgrades?
Tom
A while back I read somewhere about about how Mikrotik is going away from the #.x.y version numbers to a simpler #.x scheme.. The next major Mikrotik version will be 4.0. All fixes and updates for Mikrotik version 3 will be numbered like 3.1,3.2,3.3,…,3.20…
-Gerard
I think Mikrotik has serious categorizing issue.
most changelog in 3.1 was fixing and debuging.
it could be 3.0.1
basically every software developer copmany would call a fix in second
extension like 3.0.1 or 3.0.2
and when there is a new feature added it will be 3.1 and 3.2 and so far…
but I’m not sure if one or two new feature added did deserve 3.1 jump or not.
I think we’re gonna see 3.45 before 4.0 , unlike the mathematic fact that after 3.9 should be 4.0
what difference does it make? we just removed the first leading “2” that never changed.
that would be really nice for us to determine how much testing we need before deploying…
3.0.1 - bug fix
3.0.2 - bug fix
3.0.3 - bug fix
3.0.4 - bug fix
3.0.5 - bug fix
3.1.0 - bug fix / new feature
3.1.1 - bug fix
....
3.1.15 - bug fix
3.2.0 - bug fix / routing-test included as standard routing package
3.2.1 - bug fix
then we know when a feature or package change is done so that we can do more complete testing before deploying a new build, or when there are no features changed, feel more confident in pushing out a new build faster knowing that it is only bug fixes
what is the difference between 3.123 and 3.2.3 ?
the number of revisions won’t change anyway, you can call it A.B if you want 
I wonder why you have to resist on every single idea that is presented in this forum.
Honestly I’ve never seen you agreeing on anything.
Your idea is what we used before, since the beginning. I’m just explaining that the first digit in the RouterOS version revisions never changed (the 2.), so we removed it. nothing else will change.
You are complaining as if I just rejected some invention of yours. What you suggest is the way it already was!
If you think in terms of only two significant digits, yes. No one ever said it stopped at 3.9, did they?
The software world in general is far too hung-up on version numbering in general. When I do embedded programming, my releases are simply integers, “build” numbers if you will. I don’t artifically complicate or create importance/emphasis with major/minor/bugfix numbering, and most people don’t really care.
If you answered “Yes” to any of the above, then upgrading is probably the right thing to do. Otherwise, it’s probably best to resist the urge to upset the balance on your currently working network. Sit on your hands, gain experience with the product, evaluate it’s performance, watch for bugs or issues (and report them), and dilligently read the forums and mailing lists. When the answer to any of those questions is “Yes”, then consider upgrading - and always do so in a limited rollout fashion first, with a plan for rollback if it becomes necessary.
I’m not saying MT has a faulty product or is guilty of anything here. I am saying that you should always evaluate your reasons for upgrading regardless of what the product is or who the vendor is. And, generally speaking it would do people good to get away from the version numbering infatuation, do some reading, and make an intelligent decision on when and how to upgrade.
Brad
Since the changelog is habitually short winded and lacking in details / entire sections of what was changed, it is very difficult to read up and make that intelligent decision, which I, and many others, would most definitly like to do. I proposed an alternative version numbering scheme because MikroTik has stated many times their internal organizational and managment structure around their programmers makes it very very difficult for them to keep accurate changelog’s.
Therefore in lue of detailed changelogs, we need something to help up make an educated decision regarding upgrades, and a more meaningfull version number would help with that.
I would prefer the changelog to be more detailed over anything else (even if that means it’s 1-2 pages long per release), but since I don’t expect that to happen any time soon, so until then, maybe we can at least get a more meaningfull numbering system?
missed your question when replying yesterday Normis…
This concept has already been put in place by MikroTik with v2.9.x since the early releases of v3, when it was published that v2.9 would receive no further features, only bug fixes from here on out. I am only suggesting that we modify the existing standard so that instead of v2.9 being the major release, v3 is the major release, and the second number be incremented with each package or feature change to the release, as a form of notification that there have been underlying changes or additions to the system that warrent thorough testing.
The difference is that v3.2.3 tells me that we are running v3, it has had 2 feature additions since it was released and since the last feature release, 3 bug fix releases, where v3.123 only tells me there have been 123 changes since the initial release.
the reason this is important is because without a throughly detailed change log, we never know when a new build is simply a bug fix for the last build, or if it includes some fundamental changes to the drivers or the system, or a new package.
example of how this would work in real life:
x.0.5 - fixed bug - OpenVPN key renegotiation did not work;
x.0.6 - fixed bug - PPTP client did not work with Windows PPTP server;
x.1.0 - added layer7 protocol matching capability in firewall;
x.1.1 - fixed USB UPS detection;
x.2.0 - added support for BGP signalled VPLS;
reading this, if I were currently running version x.0.3 and running BGP, I would feel comfortable upgrading to v x.1.1 without significant testing, but before upgrading to x.2.0 I would perform lots of testing and be prepared for a quick rollback with the knowledge that the BGP components have been modified and may contain new bugs.
Essentially it is a numbering scheme that tells people how much different the new version is then the old. This information works both to promote faster adoption of new versions that contain only bug fixes by allievating the concern of rolling out a less tested update knowing that nothing else has changed, and to encourage thorough lab testing when a new version comes out, knowing there is a good reason to test it (and conversly not testing knowing when it is not as important).
Nevermind…
Of course that would be better. But it’s not so easy to implement.
I would prefer the changelog to be more detailed over anything else (even if that means it’s 1-2 pages long per release)
Yes, I agree. I would like to see much more detail in the changelogs. It’s difficult to know when and when not to upgrade versions. I think we saw this between 2.9.12 and 2.9.45 - it was very difficult to know if upgrading OS version was going to make routers more or less stable, and there wasn’t much information to go off of in the changelog (for the most part, anyways).
Essentially, we are now at that same point with 3.x. It’s out of official beta, and into customer beta testing. We’ll be seeing frequent version upgrades as changes are made and the stability of 3.x advances. I’m not specifically complaining, that’s just the way it is with every software vendor I know of any more. Instead of internal beta testing, they just let the customers do it (not a dig at Mikrotik - ALL vendors are doing this now).
I guess what I am trying to get across is in this environment it really would help us in this process if the change logs were more detailed.