[adrotate banner=”4″]
As we all patiently await the release of RouterOS (RoS) v7 beta, MikroTik has announced a change in the way RoS development is organized. There will now be three different tracks of development:
Bugfix only – When a current build is released, only fixes to known bugs will be added to this branch of development
Current – Current release will contain bugfixes and new features
Release Candidate – The release candidate will remain the development build for the next “current” release.
Graphical Overview of the new development cycle
Image and notes below are from here
A small addendum: the Bugfix only will only contain verified fixes, and no new features. The Current release contains the same fixes but also new features and other improvements, sometimes also less critical fixes than in Bugfix. And finally the Release Candidate is more likely to a nightly build. We will not to intensive testing before publishing these, only quick check if upgrade can be done and if most features work fine.
Origin
The idea originally came out of this thread and after a flurry of positive commentary, it became a working practice shortly therafter.
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 changesWe 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.
MikroTik download page gets a slight refresh with a new drop down
Thoughts
This a very positive change for MikroTik and will go a long way with customers and integrators to be able to select code based on the needs of the environment. This release cycle is very similar to other network vendors (Think of Cisco IOS General Deployment vs Maintenance Deployment) and works well.
Code selection is such a critical element to the stability of a network and it’s helpful to have the ability to load a RoS code that has been patched but without new features. It’s a bit early to tell as to how much of an impact this will make in the MikroTik community, but the results so far look promising. I’ve done upgrades on a number of CCRs and 2011 series routers from 6.30 –> 6.30.1 –> 6.30.2 bugfix only and haven’t seen any major stability issue s or other bugs when running on a BGP/MPLS/OSPF service provider network.
There was a lot of churn with bugs and working features breaking early on in 6.x and this change should help to avoid at least some of that upheaval when 7.x makes it to a “current” release.