unRAID Server Release 5.0.1-i386 and 5.0.2-rc2-i386 Available

Download

Please see

readme.txt

in the release zip file for installation/upgrade instructions.

Release 5.0.1 is different from 5.0.1-rc1 in that only the "-rc1" suffix was dropped.

Release 5.0.2-rc1 is different only in that smartmontools was upgraded to 6.2 per user request.  Seems to work.

I don't really like doing these -rc's on patch releases - what do you think, necessary?

 

Release 5.0.2-rc1 is different only in that smartmontools was upgraded to 6.2 per user request.  Seems to work.

 

Tom ---

Why was this upgrade requested? 

As far as needing a rc for this type of change, I don't think it is really necessary for changes which have aging for four months.  By that time, one would expect that any problem with the new version of a standard tool would have be detected, reported and fixed.

I agree, patch releases do not need to be labeled rc.

IMO testing is always good before release, no matter what changed, things can always go somehow wrong sometimes even on simple things as you know, however I fully agree that it's unnecessary work to fully build an rc, change changelog, etc. twice for patch releases as you are doing... I would suggest maybe a more simple way like just build it like a final release version (i.e. just final like version number hard-coded, no rc on it...), but post it 1st with a testing status (rc or whatever name it) for some time, then if all ok just rename it to final on the site, to make the final/public release, same files, no need to rebuild it, no need for users that got that version with testing status to redownload, etc...

What if a version with testing status is found to have problems you may ask? Maybe to avoid confusion releasing it multiple times with same hard-coded version I think would be ok to just jump release digit, I mean for eg. if 5.0.2 is found to have a problem while on testing status then never actually release 5.0.2 as final/public and just advance to 5.0.3...

And thanks for the new versions

I agree, patch releases do not need to be labeled rc.

+1

Thanks for the update too :-)

Sent from my Nexus 7 using Tapatalk 4

+1

I agree.  rc-1, rc-2, rc-3.....meaningless!

"rc" only implies a lack of confidence in the release. 

MUCH rather see 5.01.....5.02.....5.10......etc.

And I'd rather see no release than to see a release that implies that you're not confident enough to call it 5.02 vs. 5.01.....seriously- how much does a difference of 0.01 really represent in promises of functionality.

Just my $0.02

A beta or rc should be provided if you do some major changes like 5.0 or the upcoming 64bit edition. If you just fix some bugs or update third party software you should release it as 5.0.x like 5.0.2. If a bug should be found in 5.0.2, fix it and relase 5.0.3.

I would argue that it is semantics if it is called 5.0.1 or 5.xxx.RC, both are release candidates.

If history has shown us anything it is that unexpected problems come from trivial changes. By definition you cannot release a stable without it being tested by a larger users base so either we pull together a community testing team that gets access to pre release versions or you have to keep the RC model.

Its not like unRAID release a lot of versions, don't get bogged down in this.

I don't care what you call it.  I'm just happy to see progress and new versions with updates.  Keep them coming!

I like the definitions on Wikipedia.

http://en.wikipedia.org/wiki/Software_release_life_cycle

and

https://drupal.org/node/467020

Release candidate

A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bug. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities. Beta testers, if privately selected, will often be credited for using the release candidate as though it were a finished product. Beta testing is conducted in a client's or customer's location and to test the software from a user's perspective.

Perhaps it's best to communicate or debate this in another thread.

If you want to present an upgrade version for people to test with.

use Alpha,Beta,RC.

When you are confident that you want the whole community to upgrade to what you consider stable, then drop the suffix.

Why not upgrade the Kernel to the very latest version (3.12) instead of 3.9.11 which came out in 2013-07-21?

5.0.2-rc1 doesn't download properly.

Why not upgrade the Kernel to the very latest version (3.12) instead of 3.9.11 which came out in 2013-07-21?

I agree, 3.9.11 is dead end.  But 3.12 is too new, and not yet tested on a large scale.

I think it's best if we go with the 3.10.x series, as that's the latest LTS kernel.

(Plus, Slackware 14.1 also chose the 3.10.x kernel.)

Why not upgrade the Kernel to the very latest version (3.12) instead of 3.9.11 which came out in 2013-07-21?

I agree, 3.9.11 is dead end.

I think it's better if we go with the 3.10.x series, as that's the latest LTS kernel.

Plus, Slackware 14.1 also chose the 3.10.x kernel.

I would imagine that the 64-bit release will be using a newer Kernel and one that is used in Slackware 14.1.

I do not want to see Kernel things changing in point releases unless absolutely needed.  With all the problems we had last time with trying different Kernels, drivers, etc. chaning a little at a time is the way to go.

I would imagine that the 64-bit release will be using a newer Kernel and one that is used in Slackware 14.1.

Correct.

I would imagine that the 64-bit release will be using a newer Kernel and one that is used in Slackware 14.1.

 

Correct.

Wow, upgrade of the base system to Slackware 14.1 will be nice, there's a lot of old packages with major fixes launched since 13.1.

Tom, can you upgrade the Netatalk package to the latest release? I did some testing here, and it appear to be much more stable than the existing one: http://lime-technology.com/forum/index.php?topic=30239.0

Tom, can you upgrade the Netatalk package to the latest release? I did some testing here, and it appear to be much more stable than the existing one: http://lime-technology.com/forum/index.php?topic=30239.0

I vote +1

the webgui was extremely slow and sluggish on 5.0.1 - reverting to 5.0 immediately resolved this for me. FYI.

the webgui was extremely slow and sluggish on 5.0.1 - reverting to 5.0 immediately resolved this for me. FYI.

Now this rises the hairs on the back of my neck wel all remember the issues with SF and v5.0... no way i'm gonna try 5.0.1 if this is the case with the webgui as well...

the webgui was extremely slow and sluggish on 5.0.1 - reverting to 5.0 immediately resolved this for me. FYI.

Now this rises the hairs on the back of my neck wel all remember the issues with SF and v5.0... no way i'm gonna try 5.0.1 if this is the case with the webgui as well...

My experience is the exact opposite - the 5.0.1 release GUI seemed to be more responsive if anything.

the webgui was extremely slow and sluggish on 5.0.1 - reverting to 5.0 immediately resolved this for me. FYI.

Any plug-ins? 

Could it be related to the fact that you appear to be running in a virtual environment? 

I'm not saying that there isn't a problem, although I haven't seen any, but there could be other factors at work.

the webgui was extremely slow and sluggish on 5.0.1 - reverting to 5.0 immediately resolved this for me. FYI.

Now this rises the hairs on the back of my neck wel all remember the issues with SF and v5.0... no way i'm gonna try 5.0.1 if this is the case with the webgui as well...

My experience is the exact opposite - the 5.0.1 release GUI seemed to be more responsive if anything.

That's good to hear

I double that, 5.0.2 with stock gui (not the one on github) is working smooth and fast.

I double that, 5.0.2 with stock gui (not the one on github) is working smooth and fast.

We're talking about the webgui, not the stock gui...

unRAID 6.0 request Telnet vs SSH (Topic Split)

http://lime-technology.com/forum/index.php?topic=30273.0

Please respond there regarding the telnet vs SSH topic.