Mikrotik Release Schedule V2

vortex · Mon Apr 04, 2016 7:08 pm

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.

Mon Apr 04, 2016 7:39 pm

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.

vortex · Mon Apr 04, 2016 7:54 pm

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.

vortex · Mon Apr 04, 2016 8:38 pm

Example:

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

vortex · Tue Apr 05, 2016 2:07 am

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

vortex · Tue Apr 05, 2016 4:42 am

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.

vortex · Tue Apr 05, 2016 5:22 am

- 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.

IntrusDave · Tue Apr 05, 2016 9:01 am

current system works just fine.

Tue Apr 05, 2016 9:43 am

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.

vortex · Tue Apr 05, 2016 2:48 pm

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

This funnels better who installs what.

vortex · Tue Apr 05, 2016 3:01 pm

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

Tue Apr 05, 2016 6:11 pm

1. People who make their systems unbootable on Current

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

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).

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

3. Potential customers who read the forum and see the complaints of 1.

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.

4. People who are afraid that a future Bugfix might be borked

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.

IntrusDave · Tue Apr 05, 2016 6:22 pm

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.

vortex · Tue Apr 05, 2016 7:25 pm

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.

Tue Apr 05, 2016 7:47 pm

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.

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.

There's no additional development, just more controlled exposure.

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.

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

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.

vortex · Tue Apr 05, 2016 7:58 pm

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.

Tue Apr 05, 2016 8:23 pm

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.

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...

vortex · Tue Apr 05, 2016 8:33 pm

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

IntrusDave · Tue Apr 05, 2016 10:01 pm

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

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.

Sob · Tue Apr 05, 2016 10:03 pm

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.

IntrusDave · Tue Apr 05, 2016 10:04 pm

MikroTik's RC = alpha/nightly/...
MikroTik's Current = beta/testing/RC/...
MikroTik's Bugfix = release/stable/...

Bingo.

vortex · Tue Apr 05, 2016 10:45 pm

There is supposed to be a release for people who need new features and another for people who need absolute stability.

I am not complaining. I can see that there's a serious problem with the process (but not the chaos that preceded it).

IntrusDave · Tue Apr 05, 2016 10:49 pm

I'm pretty sure you just want to increase your post count at this point.

vortex · Tue Apr 05, 2016 10:51 pm

What for?

Sob · Tue Apr 05, 2016 11:55 pm

If you want stability (*1), use Bugfix. If you want all the newest features, use RC. If you are prepared to trade a little stability for some new features, use Current. What's the problem with that?

(*1) You can't have "absolute stability", it's not possible. Every change - even bugfix - can break something. It should be rare, but it can happen.

Lets say there are still some risks with Bugfix, mainly when the old branch is retired and replaced by newer one (X.X.x -> X.Y.x). That brings bunch of new features and might break some configs. But you can hardly avoid it. Sure, there could be X.Y.x-preview released before X.Y.x-final. But would it really make a difference if your router was broken by X.Y.x-preview instead of X.Y.x-final? You could say that you wouldn't install -preview yourself and you'd only wait for -final (after others tested -preview), but it still does not guarantee anything, see (*1).

vortex · Wed Apr 06, 2016 12:03 am

The problem is that you're not giving up a little stability with Current, some releases are completely broken.

Current is not a release level today, contrary to its aim. It is a beta program.

The AIM of Bugfix is absolute stability, that's why the introduction of new features is delayed.

The point is that some people will avoid preview until there's a sufficiently vetted release.

Audience:

Alpha < Beta < Feature RC < Bugfix RC < Feature Release < Bugfix Release

pcunite · Wed Apr 06, 2016 5:38 am

There is supposed to be a release for people who need new features and another for people who need absolute stability.

This ... I need stability, not features. Just give me a bugfix. When a new feature has been out for year, okay, I'll bite then.

Wed Apr 06, 2016 8:23 am

Guys, aren't we turning in circles? This has been discussed in the same way since the release strategy was introduced. The essential is that we all understand what each update branch means and that if there is no reason to touch working device none will touch it. Especially if someone does not have fully equipped laboratory to make the tests.

vortex · Wed Apr 06, 2016 9:35 am

I am not sure everybody understands that you cannot just go and install Current, especially with that name.

There are always new users.

Wed Apr 06, 2016 11:18 am

some releases are completely broken.

when was that? last i can remember is 6.17

pe1chl · Wed Apr 06, 2016 11:21 am

The problem is that you're not giving up a little stability with Current, some releases are completely broken.

With an attitude like that, no scheme will satisfy you.
When you want to use new software in your network, the only one responsible for the result is you.
Not the naming or scheme of releases.

vortex · Wed Apr 06, 2016 12:11 pm

Look at the Current threads to see what I mean.

Wed Apr 06, 2016 12:42 pm

Look at the Current threads to see what I mean.

LOL, have you been around this forum when V6 just become active? 6.0 -6.17 ?? Then it was problematic, now those topics are ideal. Since introduction of new release system, everyting is fine or ideal with current and bugfix, at least from my point of view.

I'm starting to think you are just Trolling here, and this topic actually makes no sense, so last post here from me.

vortex · Wed Apr 06, 2016 10:39 pm

It might be fine so far for you and me, but not for other people. I don't bury my head in the sand.

Mikrotik Release Schedule V2

Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Re: Mikrotik Release Schedule V2

Who is online