1 hour ago, ksarnelli said:

- Seeing a product with 15 real release candidates would make me lose faith in the skill set of the developers and the QA process.  That's a lot of bugs for a product that should be in a code freeze.

 

It's far more if you count up all the sub-letter releases, like RC# then RC#a then RC#b and so on.

 

Somewhere between 50 to 64 at a gut feel, but we'll never know how high some of the private Release Candidates went.

 

rc15e = 6

rc14 = 1

rc13 = 1

rc12a = 2

rc11i = 10

rc10b = 3

rc9f = 7

rc8q = 18

rc7 = 1

rc6 = unknown

rc5 = 1

rc4 = unknown

rc3 = 1

rc2 = unknown

rc1 = 1

Why do some, but not all, of the RC versions have letters behind the name?

 

These terms really have lost their meaning in many ways - after all Gmail was in beta for over 5 years.

2 hours ago, Squid said:

All software is beta.

 

Right, ask Apple about iOS11 

24 minutes ago, wayner said:

Why do some, but not all, of the RC versions have letters behind the name?

 

Because there were internal release cycles before releasing the next RC. The letter just shows which cycle eventually went public but has no further significance.

 

2 minutes ago, bonienl said:

 

Right, ask Apple about A [?]OS11 

 

Fixed that for you... 

3 hours ago, ksarnelli said:

Seeing a product with 15 real release candidates would make me lose faith in the skill set of the developers and the QA process.  That's a lot of bugs for a product that should be in a code freeze.

 

So if we call all these beta releases, your faith is restored 

7 minutes ago, bonienl said:

 

So if we call all these beta releases, your faith is restored 

 

Yes.  A beta is not a release candidate.  New features are added during a beta phase and with new features bugs are generally expected.  I would never recommend anyone run a beta unless their primary intention is to find and report bugs.

Edited December 12, 20178 yr by ksarnelli

It's only an issue for people relatively new to UNRaid.  After a couple of releases you get used to it and know when it's time for you to jump in.  I used to run all Beta.  Now, older, wiser and with 2 kids & a wife to contend with, my server needs to be more stable so I jump in around RC4 or 5.

 

If you are risk averse and do not want to take risks, wait for the released version.

 

If your complaint is the terminology used then asking LT to change that will not make the releases quicker or more stable.  So what's the point?  Changing Beta to Alpha, RC to Beta will address what this thread seems to be asking.  But then that will just delay the releases imho because people will demand RCs after Beta.

2 hours ago, dalben said:

If you are risk averse and do not want to take risks, wait for the released version.

 

The released version is not assured to be bug free (or even serous bug free). The worst bug we ever had was a bad RFS driver that went all the way to release version. The big wasn't LimeTech's fault (part of Linux) but nonetheless slipped through testing, and had a rather disastrous impact as it seemingly randomly corrupted data.

 

I agree the @Squid (treat all releases as beta), which was basically what I said earlier.

 

It's good to run a stable version that lots of users are running successfully for at least a few weeks, but more likely longer. But you need to be aware of what is in the releaae. If it contains important security updates, you might jump sooner than a release with a new feature you don't even plan to use.

 

BTW, at the beginning of the 6.4 development, LT announced that no significant changes were taking place in 6.4 to unRaid and that they would be using RCs only. No betas.

26 minutes ago, SSD said:

The worst bug we ever had was a bad RFS driver that went all the way to release version. The big wasn't LimeTech's fault (part of Linux) but nonetheless slipped through testing, and had a rather disastrous impact as it seemingly randomly corrupted data.

 

I was one that got hit by that.  If I remember there was an updated RFS driver from RC8 to RC9, or something like that.  It wasn't a bug that had been there from the start.

 

May not have been LT's fault but it hurt.

15 hours ago, Squid said:

All software is beta.

 

Taken as a whole, the 6.4's prior to RC9 was "beta".  Everything after is legitimate "RC's" as being termed here.

 

Beyond that, and the intermittent VM issues on RC15 and the continuing Ryzen issues (out of LT's control), 6.4 RCx is more "stable" than 6.3.5

Not at all.

 

All software has bugs. But to claim that all software is beta is ignoring the existing definitions. It's like redefining the meaning of words and saying all languages are latin, or that all vehicles are cars.

 

Everything after RC9 is most definitely not release candidates, since there is rewrite works planned and ongoing, and not just fixes of critical bugs. The versions may be stable. But stable and release candidate are two completely different terms with different meaning. And inventing Random Cliche, Roving Clans or Red Carpet or some other random meaning of the RC letters is just intended to confuse/misinform readers. Having done it for quite a number of years doesn't change this fact.

My opinion for what it is worth.

• Drop the RC tag. It is meaningless here but meaningful everywhere else, leading only to avoidable confusion and complaints.
• Have two branches. One testing and one release.
• Patch the release branch until the testing branch is ready to take it over and then start again. This culture we have developed where  months pass without any bug or security fixes being released is completely unprofessional.

I am happy to return to assisting with security reports but not unless we adopt the two branch model or radically reduce the time between "stable" releases.

 

Just to clarify - I have accumulated a couple of years of running unRAID beta versions. But of own choice, and knowing I have been running beta software.

 

It's good for LT and good for the users to have users help with testing new software. Especially since it takes a huge amount of different hardware and usage cases to find all possible incompatibility issues.

 

It's just when people runs beta software based on incorrect assumptions that becomes a problem. And the RC tag does result in people running beta versions based on incorrect assumptions. That isn't helpful to LT or anyone else. And doesn't save any time/money or speeds up any release process.

 

It's definitely an advantage to run a testing and a release branch, allowing the release branch to get bug fixes while the testing branch introduces new functionality. That's a concept that has worked extremely well for a large number of small and large companies. If it can work well even for one-man operations, then it most definitely isn't too administratively expensive for LT. Git and other source code management systems handles this concept extremely well, since it's more or less the standard way.

Since we all know Wikipedia is the source of truth for all things :

https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate

 

The issue, IMO, is that there is reasonably well accepted industry definition for what a "Release Candidate" is.  By that measure, the 6.4 releases of unRAID have not been release candidates.  Alphas, Betas, Previews, pre-productions releases - call it what you like.  But not Release Candidates - that terms sets an expectation that the software is very stable and close to final code.

 

I'm solidly in favor of the community participating in pre-production releases.  But I'd prefer that Limetech not use an industry standard term in an unconventional way.

Edited December 13, 20178 yr by tdallen

13 hours ago, dalben said:

If you are risk averse and do not want to take risks, wait for the released version.

Even better, wait for the first hotfix for the released version and then jump on it!

 

forgot to mention:

Never change a running system! (if you don't have to!)

Edited December 13, 20178 yr by Fireball3

Funny how this same subject comes up every couple of years.  Its a very circular argument, and at the end of the day nothing is going to change.

 

This is how it appears that LT defines Beta / RC. 

 

Beta - Fundamental changes to the underlying system

• 5.0 Beta x - Support for GPT drives
• 6.0 Beta x - Switch to 64 bit system, sorting out which to use XEN or KVM
• 6.2 Beta x - Support for Dual Parity

Release Candidate - Changes which do not affect the underlying system (including CVE's, kernel updates, etc)

• 6.0 RC's - Refinements to Dynamix
• 6.1 RC's - WebUI security enhancements
• 6.2 RC's- Further UI enhancements to UI
• 6.3 RC's - Security Enhancements, UI Enhancements
• 6.4 RC's - Encryption, SSH - (None of which affect the underlying system), UI overhaul

Stable - When no more bugs / issues appear within the 6.4 RC's

 

Based upon their definition (which depending upon your view point is either correct or incorrect), the RC's is not a feature freeze but allows for enhancements / additions when that suits the end-goals for the ultimate stable release.

 

IMHO their definition is suitable (not necessarily correct) since it lets you know when your data may be at risk and when it is not.

 

And, stable is a misnomer to begin with, as it implies that the version in question is bug free.  All of the 6.4 RC's are more "stable" than 6.3.5 when used in the same context as 6.3.5

 

 

I would say that there have been fundamental changes that have impacted the underlying system in 6.4 RCs, specifically all the changes to emHttpd. That deserves a larger change acknowledgment than a "UI overhaul" tag implies.

 

3 hours ago, Squid said:

Funny how this same subject comes up every couple of years.  Its a very circular argument, and at the end of the day nothing is going to change.

I'm not really sure what is funny about this. The subject comes up every couple of years because people find an issue with a supplier that implies that beta releases are release candidates. Next thing - you say nothing is going to change, which implies that you, yourself, have figured out that LT are stubborn. That's also something that can be argued if that is a good thing or should be seen as funny.

 

3 hours ago, Squid said:

This is how it appears that LT defines Beta / RC. 

Don't you see the problem with your sentence? You need to debate how it appears that LT define beta/RC, ... If using the more traditional definition, then the users wouldn't have to spend time trying to figure out how it appears to be. That's also why the world got dictionaries, allowing people to look up definitions of terms instead of spending time trying to figure out what they appear to mean.

 

3 hours ago, Squid said:

And, stable is a misnomer to begin with, as it implies that the version in question is bug free.  All of the 6.4 RC's are more "stable" than 6.3.5 when used in the same context as 6.3.5

No, stable is not a misnomer since stable has never been intended to mean bug free, just as "red" has never been intended to mean "eatable", and beta has never been intended to mean buggy.

 

Stable code is code that isn't intended to be changed. And that's the reason for the code freeze that is part of the traditional definition of a release candidate, and why it after a code freeze takes a separate step to decide if a bug fix may be incorporated or not - the bug represents a known and stable state while the bug fix may introduce an unknown side effect and invalidates already performed testing.

 

In the end, LT is using a release model that most other companies have found not working very well. Some day, possibly after many years and several more threads like this, LT might figure out why other companies have adjusted their release models. Spending 30 years developing software, I have had the chance to test a number of release models and not all works equally well.

5 minutes ago, pwm said:

That's also why the world got dictionaries

Oh.  Didn't realize that such a thing as homonyms exist.  Where the same word spelled and pronounced the same way mean completely different things depending upon the context.  

 

Doesn't matter.  Debate all you want about what the definition is of RC vs Beta vs Stable.  At the end of the day its not going to change what LT feels that the meaning is in relationship to their product and philosophy.  I simply gave you a reasonable explanation of what they feel is a beta vs a rc based upon their release history. 

 

Its funny because this is all about semantics and word meanings. 

Yes, it's semantics, but it matters to anyone who understands the software development life cycle.

 

Let's say I prefer my steak well done*.  If it comes out medium-rare I'm not eating it, but if it comes out medium-well I'll probably eat it depending on how hungry I am.

 

If I'm desperate for a feature that is included in the next release I may consider running an RC, but I would never run a beta.  When developers veer away from the standard definitions of these it becomes confusing/misleading for the end users.

 

* PSA - Never order your steak well done 

3 minutes ago, ksarnelli said:

If I'm desperate for a feature that is included in the next release I may consider running an RC, but I would never run a beta

And you're not alone there.  On LT's beta releases I always wait a while.  On their RC's I have no problems running them on production servers.  But that's because of how I interpret that they define Beta (data at risk) & RC (data safe).

 

But my opinion is that under the "standard" definition of RC everything past 6.4-RC9 does meet that qualification.  Prior to that it would meet the "standard" definition of Beta.  But that's entirely my opinion, and I may be in left field on that one.

 

The real thing here is just what is the hold up on going from RC to Stable.  For all we know it may be the Ryzen issues which may continue for a while, and in the meantime more fixes etc will get added to the system as they are found (including long standing / forgotten issues that may have existed on 6.3 and before), as nobody has anything else to do until AMD fixes their own problems.

 

 

 

3 minutes ago, Squid said:

The real thing here is just what is the hold up on going from RC to Stable.  For all we know it may be the Ryzen issues which may continue for a while, and in the meantime more fixes etc will get added to the system as they are found (including long standing / forgotten issues that may have existed on 6.3 and before), as nobody has anything else to do until AMD fixes their own problems.

 

As I already noted earlier - stable and bug-free are two separate concepts.

 

Which also means that a different release model can allow version 6.3.6, 6.3.7, ... to be released with new features and with misc bug fixes but without any fix for Ryzen, while a separate branch fights with attempted Ryzen fixes and the development branch introduces new features that are then moved to testing and further into the release branch - possibly in different order compared to the order of implementation.

 

A monolithical release process tends to get big problems with delays if one feature ends up being harder than intended to implement or to get through the test phase. And it has a hard time handling changed requirements, where a new requirement might pop up during the development cycle.

 

That's why companies moves (or have already moved) to agile release management practices and agile development processes. It's just that lots of companies takes the first step with agile development, but forgets to also introduce agile release management.

Serious thread is serious.

HaHa and to think this newbie just couldn't figure out where the:

 

Update OS (-rc5)

Instead of bundling an "unRAID Server" plugin on the Plugins page, there is a new page on the Tools menu in the About section called 'Update OS'.  Here you can check for a new unRAID OS release as well as switch between the latest release in the stable branch or the next branch.  In addition there is a separate control on the Notification Settings page that configures whether or not to automatically check for updates.

 

HaHa been looking for weeks my issue is now solved!

> Beyond that, and the intermittent VM issues on RC15 and the continuing Ryzen issues (out of LT's control), 6.4 RCx is more "stable" than 6.3.5

 

So if I don't use VMs and have Intel... I'd be more stable switching at this point? (Tons of Docker usage..)