limetech

unRAID Server OS mainline release branch

Recommended Posts

Here at Lime Technology we manage two release branches: stable and mainline.  The stable branch is for those users who want better tested, though less frequent releases.  The mainline branch (also sometimes called "next") is where all new development takes place.

 

tldr: to get on the mainline release branch, install this plugin:

https://raw.githubusercontent.com/limetech/webgui/master/plugins/unRAIDServer/unRAIDServer.plg

 

[glow=red,2,300]EDIT: Please don't use this topic to talk about specific features or issues.  Such posts will be removed - no malice intended.[/glow]

 

Stable Releases

Stable releases are numbered <major>.<minor>.<patch> as in:

6.2.0

6.2.1

6.2.2

6.3.0

6.3.1

etc.

 

Completion of a new feature or improvement set typically increments the <minor> number.

 

Patch releases are reserved exclusively for CVE's and other critical bug fixes.  CVE's and critical bug fixes appear in a mainline release for testing first, and then are back ported to the latest stable.

 

At this time, whenever a new stable release is published, all previous stable releases are deemed EOS (End of Support).

 

Mainline Releases

Mainline releases are numbered <major>.<minor>.0-yyyy.mm.dd as in:

6.3.0-2016-09-24

6.3.0-2016-09-26

etc.

 

If we need to publish a second mainline release on the same day we will add a letter suffix:

6.3.0-2016-09-26a

 

The mainline branch is where all the development is taking place.  There may be several mainline incremental releases before finally the feature/improvement set goals are met for the next stable release.  At that point we create the next stable release branch and publish a new stable minor release.

 

Our intent is that each incremental mainline release is fully functional.  It must be assumed however, that lurking bugs may exist in incremental mainline releases that can cause instability.  If a feature/improvement incremental release carries a risk of data loss, that will be separately noted in the release notes.

 

Note that an incremental mainline release usually involves updating both unRAID-OS and the webGUI component (dynamix).  In this case a server reboot will be necessary.  It is also possible that an incremental release only updates the webGUI component, which typically will not require a reboot.

 

Differences From Previous Release Methodology

  • Gone are the days of lengthy and arbitrarily labeled beta/rc releases cycles.
  • Also gone are individual Announcement posts of incremental mainline releases.  We will post a single new topic at the beginning of a new mainline release cycle that will outline the feature/improvement goals for the next stable release and serve as the thread for user feedback.
  • We are anticipating this new methodology will bring developers closer to users and accelerate distributed development.
  • Stable releases will be generated at a much faster pace.

 

Final Note

Ok the first version being installed from the mainline branch using the above plugin is actually labeled 6.2.1-2016-09-22.  Hence it's not really a true mainline release (as defined above).  We are doing it this way because the only thing in there are CVE patches and we want to follow the rule where CVE's and critical bug fixes are tested in mainline first.  The 6.2.1 stable release branch will be created from this mainline release, and the next mainline release should be 6.3.0-<date>.

Share this post


Link to post
Share on other sites

just a quick question: Linux kernel changes - in winch branch they will go? or it depends?

In a stable release we would stay on the same linux kernel minor release and only update to a later kernel patch release in order to pick up a CVE or critical bug fix.  For example, for unRaid 6.2.1 we updated from kernel 4.4.19 to 4.4.21 because there were a couple CVE patches in there.  A new minor kernel release by itself probably would not warrant us publishing a new unRaid stable release.

Share this post


Link to post
Share on other sites

just a quick question: Linux kernel changes - in winch branch they will go? or it depends?

In a stable release we would stay on the same linux kernel minor release and only update to a later kernel patch release in order to pick up a CVE or critical bug fix.  For example, for unRaid 6.2.1 we updated from kernel 4.4.19 to 4.4.21 because there were a couple CVE patches in there.  A new minor kernel release by itself probably would not warrant us publishing a new unRaid stable release.

 

thanks for info - i'm just on hope, kernel changes will fix esxi usb pass-through issue as they did in version 6.1.9..

this is a showstopper for me to move on 6.2

Share this post


Link to post
Share on other sites

I'd like to ask that minor releases' version string follow semver.

 

That is, 6.3.0 rather than 6.3

 

6.2-stable internal version string is 6.2 (instead of 6.2.0) which doesn't follow semver and it broke ControlR (semver libraries expect that .0) :D

 

I have now taken some precautions to guard against that, but it would be cleaner to get it right from the source.

Share this post


Link to post
Share on other sites

If one decides to move to the Mainline release track, will it be a simple manner to return to the Stable release track?

 

Share this post


Link to post
Share on other sites

If one decides to move to the Mainline release track, will it be a simple manner to return to the Stable release track?

 

This is my question also, for example I go to the mainline and find my sas controller isn't working.

 

I would imagine I uninstall the plugin and restore the older version  from the usb

 

But what happens then if my last version was another mainline version and I need to get back to stable?

 

Jamie

Share this post


Link to post
Share on other sites

I'd like to ask that minor releases' version string follow semver.

 

That is, 6.3.0 rather than 6.3

 

6.2-stable internal version string is 6.2 (instead of 6.2.0) which doesn't follow semver and it broke ControlR (semver libraries expect that)

 

Agree and would like to +1 this recommendation. Semantic Versioning is pretty standard industry best-practice and really helps with version consistency (I use it for the Tron project). Would it be possible to always use a minimum of 3 digits to represent version number?

 

e.g. use 6.3.0 instead of 6.3 as jbrodriguez stated.

Share this post


Link to post
Share on other sites

 

Mainline Releases

Mainline releases are numbered <major>.<minor>.0-yyyy.mm.dd as in:

6.3.0-2016-09-24

6.3.0-2016-09-26

etc.

 

One problem.  The versioning won't work properly

 

If the mainline releases as listed in the example above are FOR the 6.3.0 stable release, then that will not work, because 6.3.0-2016-09-24 is a later version than 6.3.0 when checking using standard version libraries / functions. 

 

With your 6.2.1-2016-09-22, that is available, all versions checks will fail, because 6.2.1-2016-09-22 is a later version than 6.2.1  The version should be 6.2.0-2016-09-22

Share this post


Link to post
Share on other sites

I'd like to ask that minor releases' version string follow semver.

 

That is, 6.3.0 rather than 6.3

 

6.2-stable internal version string is 6.2 (instead of 6.2.0) which doesn't follow semver and it broke ControlR (semver libraries expect that)

 

Agree and would like to +1 this recommendation. Semantic Versioning is pretty standard industry best-practice and really helps with version consistency (I use it for the Tron project). Would it be possible to always use a minimum of 3 digits to represent version number?

 

e.g. use 6.3.0 instead of 6.3 as jbrodriguez stated.

 

Right on, I tried coining this idea too a while back: https://github.com/limetech/dynamix/issues/65#issuecomment-119211753

 

Share this post


Link to post
Share on other sites

What is the expectation as far as support if one moves to the mainline branch (understanding that it could be the wild wild west)?  I imagine it has to be assumed that there is a certain level of risk.

 

John

Share this post


Link to post
Share on other sites

I'd like to ask that minor releases' version string follow semver.

 

That is, 6.3.0 rather than 6.3

 

6.2-stable internal version string is 6.2 (instead of 6.2.0) which doesn't follow semver and it broke ControlR (semver libraries expect that .0) :D

 

I have now taken some precautions to guard against that, but it would be cleaner to get it right from the source.

Sure, moving forward we'll do that.

Modified OP.

Share this post


Link to post
Share on other sites

What is the expectation as far as support if one moves to the mainline branch (understanding that it could be the wild wild west)?  I imagine it has to be assumed that there is a certain level of risk.

 

John

 

From the first post:

 

Our intent is that each incremental mainline release is fully functional.  It must be assumed however, that lurking bugs may exist in incremental mainline releases that can cause instability.  If a feature/improvement incremental release carries a risk of data loss, that will be separately noted in the release notes.

Share this post


Link to post
Share on other sites

Does the Mainline release include dynamix bleeding edge or the "normal" one?

 

The public github repo for dynamix used in unRAID OS has been renamed to "webgui":

https://github.com/limetech/webgui

 

At present there are two branches in there:

master - this is the branch referenced by mainline unRAID OS releases

6.2 - this is the branch referenced by unRAID OS 6.2.x stable releases (or will starting with 6.2.1 stable release).

 

Part of releasing 6.3.0 stable will be to create a new 6.3 branch in webgui that will be referenced by 6.3.x stable releases.

 

All of these repos will be left for legacy purposes, but no further development:

unRAIDServer

unRAIDServer-6.2

dynamix

dynamix-6.2

unRAIDServer-6.1

 

At some future date we will delete those repos.

Share this post


Link to post
Share on other sites

If one decides to move to the Mainline release track, will it be a simple manner to return to the Stable release track?

At present it's just like the old beta/rc releases.  If you want to install latest stable release, the best way is going to be to extract bzimage and bzroot* from the zip file to the root of your usb boot flash and then reboot.  However it would not be difficult for us to provide a couple buttons:

 

(if running stable) Switch to latest Mainline

(if running mainline) Switch to latest Stable

 

That feature will show up in a mainline release first  ;)

Share this post


Link to post
Share on other sites

If the mainline releases as listed in the example above are FOR the 6.3.0 stable release, then that will not work, because 6.3.0-2016-09-24 is a later version than 6.3.0 when checking using standard version libraries / functions. 

 

Please explain this issue.  No version strings in the stable branch will have a date suffix and all version strings in the mainline branch will have a date suffix.

Share this post


Link to post
Share on other sites

If one decides to move to the Mainline release track, will it be a simple manner to return to the Stable release track?

At present it's just like the old beta/rc releases.  If you want to install latest stable release, the best way is going to be to extract bzimage and bzroot* from the zip file to the root of your usb boot flash and then reboot.  However it would not be difficult for us to provide a couple buttons:

 

(if running stable) Switch to latest Mainline

(if running mainline) Switch to latest Stable

 

That feature will show up in a mainline release first  ;)

 

Sounds like that would work and be very clean and easy.  The other way that I thought of was to list the plugin-install link for the stable release (as well as the link to download the full package) in the first post for the thread for each stable release.  But your approach would be very, very simple for any expertise level of user and virtually bullet-proof!

Share this post


Link to post
Share on other sites

 

Mainline Releases

Mainline releases are numbered <major>.<minor>.0-yyyy.mm.dd as in:

6.3.0-2016-09-24

6.3.0-2016-09-26

etc.

 

One problem.  The versioning won't work properly

 

If the mainline releases as listed in the example above are FOR the 6.3.0 stable release, then that will not work, because 6.3.0-2016-09-24 is a later version than 6.3.0 when checking using standard version libraries / functions. 

 

With your 6.2.1-2016-09-22, that is available, all versions checks will fail, because 6.2.1-2016-09-22 is a later version than 6.2.1  The version should be 6.2.0-2016-09-22

 

That Semantic Versioning paper stipulates that the subsequent info (a date in this case) always indicates a pre-release, and therefore in this one case, 6.2.1-2016-09-22 always precedes 6.2.1.  In this one case, version checking routines will need to change to reverse the lexical comparison.  The first 3 quantities are checked first, but if equal, a lack of additional info indicates a final release, over any release with additional info attached.

Share this post


Link to post
Share on other sites

If the mainline releases as listed in the example above are FOR the 6.3.0 stable release, then that will not work, because 6.3.0-2016-09-24 is a later version than 6.3.0 when checking using standard version libraries / functions. 

 

Please explain this issue.  No version strings in the stable branch will have a date suffix and all version strings in the mainline branch will have a date suffix.

 

I made a quick test on how PHP's version_compare reports newer versions.

 

6.3.0 <--> 6.3.0-2016-09-24 it reports the second string as newer

6.3.0 <--> 6.3.0-V2016-09-24 it reports the first string as newer

 

6.3.0-V2016-09-25 <--> 6.3.0-V2016-09-24 it reports the first string as newer

 

I propose to change naming of mainline releases slightly and include a letter, e.g. V this will ensure they are never considered newer than the stable release.

 

Edit: typos

 

Share this post


Link to post
Share on other sites

If the mainline releases as listed in the example above are FOR the 6.3.0 stable release, then that will not work, because 6.3.0-2016-09-24 is a later version than 6.3.0 when checking using standard version libraries / functions. 

 

Please explain this issue.  No version strings in the stable branch will have a date suffix and all version strings in the mainline branch will have a date suffix.

 

I made a quick test on how PHP's version_compare reports newer versions.

 

6.3.0 <--> 6.3.0-2016-09-24 it reports the second string as newer

6.3.0 <--> 6.3.0-V2016-09-24 it reports the first string as newer

 

6.3.0-V2016-09-25 <--> 6.3.0-V2016-09-24 it reports the first string as newer

 

I propose to change naming of mainline releases slightly and include a letter, e.g. V this will ensure they are never considered newer than the stable release.

 

Edit: typos

 

When would it ever occur that you are comparing a stable version number against a mainline version number?

 

That is, when would this comparison

6.3.0 <--> 6.3.0-2016-09-24

ever be made?

 

Share this post


Link to post
Share on other sites

If the mainline releases as listed in the example above are FOR the 6.3.0 stable release, then that will not work, because 6.3.0-2016-09-24 is a later version than 6.3.0 when checking using standard version libraries / functions. 

 

Please explain this issue.  No version strings in the stable branch will have a date suffix and all version strings in the mainline branch will have a date suffix.

 

I made a quick test on how PHP's version_compare reports newer versions.

 

6.3.0 <--> 6.3.0-2016-09-24 it reports the second string as newer

6.3.0 <--> 6.3.0-V2016-09-24 it reports the first string as newer

 

6.3.0-V2016-09-25 <--> 6.3.0-V2016-09-24 it reports the first string as newer

 

I propose to change naming of mainline releases slightly and include a letter, e.g. V this will ensure they are never considered newer than the stable release.

 

Edit: typos

 

When would it ever occur that you are comparing a stable version number against a mainline version number?

 

That is, when would this comparison

6.3.0 <--> 6.3.0-2016-09-24

ever be made?

 

I am not sure it will ever occur or not. The sequence in your new release strategy would exclude a 'same' mainline release after a stable release and won't need this kind of comparison.

 

The proposal is more a safety precaution in case something unexpected happens, e.g. an out-of-sequence update.

 

Share this post


Link to post
Share on other sites

Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.