Mikrotik Release Schedule V2

RouterOS General
1

OK, the original topic is locked, so I am making a new thread to keep the discussion separate, as requested.

Let me start by saying that what was already implemented is a major improvement, as the impression I get from the forum is that there is a lot less conflict, and that personally I have been happy living in Bugfix.

However, there is still room for improvement:

  • Make Bugfix and Current as safe as to confident enough to implement automatic updates.
  • It is unacceptable that people needing a new, but tested, feature risk making their equipment unbootable.
  • It should be relatively safe for users with a small problem to manually qualify a new release.
  • People who need an unreleased new feature should be able to try it without living on the bleeding edge.
  • And some people just want to be exactly there

This is a closed source project, so how best to approach the bleeding edge is out of the scope of this post.

So, about regular users, there are 2 parallels flows, Feature and Bugfix. You can the select a flow and a stage for your installation:

Feature: Beta → RC → Release

Bugfix: Beta → RC → Release

What is now known as “RC” would be Alpha, or Nightly, depending on how Mikrotik wants to manage it, and there could be several to choose from, for different development branches, or just one for the main branch. These do not flow directly into a Beta, which could be a merge of several branches.

What is now known as “Current” would be Beta Feature. It could happen occasionally, that this will make a device unbootable (as it happens now). A handful of iterations should be enough to move to RC for wider qualification.

RCs should be quite safe, with most of the time RC1 or RC2 moving to Release.

2

May I use my both hands to vote against!!!

Do you understand that what you suggest will require twice the development time as compared to what we have now? With hardly any real benefit…

I may agree that the current release branch naming is not perfect. I’m fine with it, but I see an increasing number of people here who are not. But otherwise, please do not ask for making difficult things even more challenging.

3

This is not that different. Support for multiple alpha branches is not a requirement. Neither is immediate implementation of automatic updates.

Currently Bugfix is just released without any community vetting.

Current is not safe.

RC is currently just Alpha.

4

Example:

B1 B2 B3 B4 B5 RC1 B6 B7 RC2 R B1 B2 …

5

Let’s see if I manage to draw this:

A1 A2 A3 A4 A5 A6 A7 A8 A9 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A1 A2 A3 A4 A5 A1 ...
                           B1 B2 B3 B4 B5     B6 B7 B8     B1 B2 B3 B4     B1 ...
                                          RC1          RC2             RC1
                                                           R               R
6

Alpha: usually there will be serious problems
Beta: sometimes there will be serious problems
RC: it should be rare to have serious problems, but you have been warned
Release: It is unacceptable to have serious problems, if it happens it is a massive FAIL.

7
  • Why should there still be Feature and Bugfix?

Because Feature Release may not have serious problems, but it might still introduce some regressions in old functionality.

  • Could there be Bugfix RC but not Bugfix Beta stage?

Maybe.

  • Isn’t this a lot more work?

Alpha is already happening as “RC”. Beta is already happening as Current. Real RC is the previous very good Beta tested by more people. Release is the accepted RC.

There’s people installing Current that really want Feature Release and don’t want to play Beta roulette.

8

current system works just fine.

9

lets, just try to understand one thing - RouterOS have so many features that can be used in so many combinations, that it is impossible to test it all.
So any release system will have a possibility to once in a while have a broken release. and this is true to all software developer companies even such as Apple and Cisco.

Current system 6.xxRCzz, 6.xx.yy where
zz indicates build that adds new features and all fixes (confirmed and unconfirmed)
xx indicates determined set of features
yy indicates build with confirmed fixes for this set of features.

from software development point of view, this is optimal to combine rapid development and getting feedback from users.

Release channels (development, RC, Current and Bugfix) is nothing more than marketing interface for build system. So i do not see the point of discussing it at all, al lthat matters is “6.xxRCzz, 6.xx.yy” build system, that is working very good, and adding one more “beta” stage only slow things down.

10

There’s no additional beta stage. What there should be are a real RC and a real release.

This funnels better who installs what.

11

Current system is not working well for:

  1. People who make their systems unbootable on Current
  2. Individual users like me who stay on Bugfix and never try Current because they are too scared of messing their setup (which means less people testing Current for smaller problems).
  3. Potential customers who read the forum and see the complaints of 1.
  4. People who are afraid that a future Bugfix might be borked
12

Test before you deploy! Always! No exception!
Another beta stream won’t make any difference, an update will still potentially render your system unbootable.

What’s wrong with this? How on earth another beta stream will make it better?

The forum is here for people to complain. Happy users rarely post success stories here. Having read some complains on the forum, clever people test twice before they deploy.

Yes, Bugfix release may still be broken for some users. There’s nothing anyone can do. Period. Another beta stream won’t guarantee that it will work for everyone as expected. Let me repeat again: test before you deploy.

13

Any self respecting network admin has a “live” and “test” network. You never “test” on your “live” network. Adding to Mikrotik’s workload isn’t going to make you a better admin.

Most of us here have duplicated of each device out in the field. We mostly keep the “bug fix” release installed. When an issue comes up, we “test” the current and RC’s to see how they will function. But ONLY on the test network. If you don’t have the financing to buy two of everything, then maybe you shouldn’t be managing networks.

14

I did not have problems because I stay on Bugfix and waited until others bit the dust, as it happened once.

I don’t have another Mikrotik, and as a home user I am not supposed to test in a lab first.

It would be important to eventually have automatic Release updates for security. For this, you need a proper release procedure.

Current is not supposed to be beta. People here still don’t understand this. RC is a duplicate of a good beta, and Release is a duplicate of a good RC. There’s no additional development, just more controlled exposure.

If people feel safe enough about moving to Current, there will be more testing, and it will be possible to retire Bugfix versions earlier.

15

That’s just a question of naming. You just have to get used to it, since there’s no single naming conventions that satisfy everyone. For me, for instance, as a long-term FreeBSD user, “CURRENT” means bleeding edge, but YMMV.

I don’t know what you do for a leaving. My primary job is software development, and I surely know how this industry works. I may assure you that each additional branch that you need to keep stable and not outdated at the same time is a log of effort. And there IS additional development. To expose something, you need to have this something. And complexity grows exponentially with each additional release branch that you need to maintain.

Retiring Bugfix early is not necessarily a good thing. The current Bugfix branch is stable for (roughly) half a year already, and I won’t find enough words to express how happy I am. :slight_smile:

16

Current is a bad name invented by Miktrok. It is supposed to mean Feature, not Beta.

Real RC and Release are not development cycles, they are distribution cycles.

Look at the Current threads, they cycle rapidly with serious errors. This is not the way it’s supposed to be. This cycling is supposed to happen in a beta cycle, with the people subscribed to a Feature release being guaranteed of no drama.

Bugfix is not supposed to be stable compared to Current. Current is also supposed to be stable. The difference is that in Bugfix regressions to older functionality are unacceptable too.

If Current is guaranteed to be a safe release, then it will be a good name.

17

Again, that’s just a matter of naming. If you don’t like the current naming it does not mean the naming is bad. It just means you don’t like it.

I’ll probably quit this discussion; it seems to gradually become pointless, as you just keep reiterating yourself…

18

It is not just naming. Current is now both a beta cycle and a release that is supposed to be safe.

19

You said it all right there. Stick to the Bug Fix releases and quit whining. Or buy a Linksys or something that you can Tomato on. Then you can have a specific beta name.

20

It is just naming, trust me. Create a mapping in your mind (adjust according to your preferences):

MikroTik’s RC = alpha/nightly/…
MikroTik’s Current = beta/testing/RC/…
MikroTik’s Bugfix = release/stable/…

… then think about it like this and you’ll be happy. I did it myself and it works great. :slight_smile: