Straight away excellent work on getting these new versions out. I have a couple of questions (please these are questions only no flames)

 

4.4 Stable has a big change log. Posted here for refference

 

Changes from 4.4-beta2 to 4.4

-----------------------------

 

New features:

- Added per-disk spindown controls.

- Share 'split-level' may now be a string which marks 'constrained' directories.

- Experimental PAE support (support memory up to 64GB).

 

Improvements:

- Upgrade to linux kernel 2.6.27.7.

- Upgrade to samba 3.2.3.

- Upgrade to slackware 12.1

- Upgrade memtest86+ to version 2.01.  Note in addition to the ususal upgrade instructions below, you must also copy 'memtest' from this releae to the root of your flash.

- Restore driver logging of disk 'import' messages to allow for better debugging.

- Changed 'pseudo permissions' for the Flash device.

- Get rid of annoying "kernel time sync status change" messages generated by ntpd.

 

Other:

- Get rid of smbfs, use CIFS instead.

- Auto-generate '/etc/hosts' file to add server's hostname as additional alias for 'localhost'.

- Include 'wins' as last step in tcp hostname resolution.

- Added 'wget' package.

 

Is it wise to give it a non beta version number when its had no community testing. Many times in this forum has there been positive and negative comments over the long beta cycle but this release seems to throw that to the wind.

 

It also seems that 4.5-beta1 has a bug fix for an improvement made in 4.4

 

Bug fix:

- Changed 'pseudo permissions' for the Flash device (hopefully got it right this time).

 

Can I humbly suggest that this is a bit confusing.

 

 

Edit: BLOODY great releases though. PAE and wget are 2 of my personal wishlist. Kudos

 

I think given that some issues are being found with the 4.4 stable the points i raised here should be taken into consideration sooner rather than later

 

Its not the end of the world (since its only a name) but with that name comes the fact that some people will upgrade expecting it to be tested to the extreme levels of the previous stables.

 

Potentially the best way to deal with this would be to release a new 4.4 beta with the fixes and tag it release candidate one rather than 4.4.1. It likely wont take long to finalise the 4.4 testing with the level of community involvement we have here and this should iron out any other issues people are having.

 

The 4.5 branch can be tested as an experiment into NFS independently and simultaneously.

 

 

 

 

OK again im not flaming but i really think its worth looking at the way stables are being released without being beta tested.

 

Today seen 4.4.1 released only to be replaced almost immediately with bug fix 4.4.2 version.

 

In my humble opinion no stable should be released without it being a beta/rc first.

 

It also makes it much more confusing with a 4.5 branch beta out there with a known bug thats fixed in the 4.4 branch but not yet fixed in the 4.5/

 

You may think this is semantics but the reputation of unRAID being rock solid relies on it and if we had followed this procedure neither of these releases would be in the stable branch.

 

Kudos

 

Edit: again great content releases though

I'm not sure its that big of an issue.  The bugs that were fixed are like patches or security updates that MS would send out they just don't change the version each time.  As for the 4.5 beta 1 that was explained too as beta 2 is coming out soon.  I definitely think releasing 4.4.1 and then 4.4.2 was the correct answer since their was a need.

 

I do though think that there should be a "UnRAID BETA" forum for all posts concerning the beta version.  Also  I think the main forum page could be cleaned up with 4.0/4.1 and 3.0 being put into an archived folder.

 

Erik

I'm not sure its that big of an issue.  The bugs that were fixed are like patches or security updates that MS would send out they just don't change the version each time.  As for the 4.5 beta 1 that was explained too as beta 2 is coming out soon.  I definitely think releasing 4.4.1 and then 4.4.2 was the correct answer since their was a need.

 

I do though think that there should be a "UnRAID BETA" forum for all posts concerning the beta version.  Also  I think the main forum page could be cleaned up with 4.0/4.1 and 3.0 being put into an archived folder.

 

Erik

All this is true, but it appears as if the bigger issue was the introduction of new features in between the "beta" version and the "final" version.  There really should have been another "beta/release candidate" that after deployment would then simply be re-compiled with only one change, the "version number"

 

It is (somewhat) easy for us who follow this forum to know when a release is not working properly, but to somebody that was "shipped" a new server with a release that had never been released or tested by the masses... I think they will have a much more difficult time. They'll not know why their system is working the way it is. (or not). 

 

The unRAID BETA forum is a great idea.  So would a limited distribution of a new release, final or beta...If it works for a small number of people, with diverse hardware and LAN clients when announced in the UnRaidBETA forum, then do the formal announcement in the "Announcements" forum. 

 

We always did a limited release of any major changes to "power users and process owners" when we did software upgrades in the corporate world.  they sometimes found things we did not on our own testing...  It would easily work the same way here.

 

Joe L.

In some ways the very nature of unRAID slow stable releases actually benefits the ...." stable, beta, beta, release candidate, stable" model.

 

I dont think this forum represents the majority of unRAID users but it almost certainly represents the beta testers. I for one would welcome less frequent stable releases in favor of lots of beta releases as we as a community iron out bugs and request new features/experiment. Every now and again, perhaps even on a fixed bi yearly basis the beta could be feature frozen and worked on solely for bugs.

 

These are just suggestions but its a model that works for alot, if not most?, projects.

 

 

I'm not one for meddling in another developer's code/release process.  But in my case, I never make any code changes between the last beta or RC, and the stable.  Only change the version string.  I don't necessarily follow that to the letter, I have been known to change something like a spelling error or dialog messages, but it is a good practice to shoot for.

I agree with everything that has been said here.  I think a little to much was changed from the 4.4 betas to the final release.  4.4.1 came out fairly quickly and then almost immediately 4.4.2 was released.  Hopefully now it is a little more stable and things like BubbaRaid can build off of it.

 

A unRaidBETA forum i believe would be a very good idea.  Sticky the new beta releases at the top and open it up for discussion so that bugs and problems can be pointed out.  Once it appears a beta has been put through the ringer and nothing appears to be wrong with it, change the version name and make it the stable release.  That i think is the best course of action.

I'm just glad Tom is an active developer again, and working on new functionality.  I'm not overly concerned about the labels on each new release.  I tend to look at the changes from the prior version and wait for the dust to settle before upgrading my production array.

 

In truth, 4.4 beta 2 should have become 4.4 final, because it was stable for a long time.

 

I realized that 4.4 final was going to be like a beta release.  I think the reason he did what he did is because he wanted to release the 4.4 version and didn't want NFS support (which was very new) in the release.