I am aware the difference between free vs. paid update offers.
Since I will not be updating often, I am wondering how often do stable updates get released for free users as well?
And how easy is installing such an update on a live system?
The exact how-often question is a tricky one as we have recently transitioned from being CentOS based to being openSUSE based. That took an immense effort but was worth it given our new base OS’s support of btrfs and our prior hosts hostility to the same. Oh and them changing their tack of course. But this transition slowed our release cadence some what. And we have begun yet another major transition as we move all our base technologies along in our next testing branch which as begun but has not yet reached usable status, but nearly. And give we have for years now had usable testing releases there is a false expectation that testing is always usable. It will not be, at least at the beginning of it’s ‘run’. But as you see we work towards making testing usable ready for it’s tagging and release as stable at points just prior to making new major changes. The last stable tagging was just after the openSUSE transition and was followed by what was essentially a long field test which as resulting in our best yet release of 4.1.0-0. But of course each stable release is intended to be our best yet ;).
In short I at least can’t answer the frequency of release as this can only be based on observable performance and we have had the OS transition, and we now have the base technologies transition ongoing with our recent Django update in the testing branch that will hopefully soon result in our first testing channel rpm release based on our new base OS of openSUSE.
The following forum post has some relevant info in hopefully:
If on the other hand you are asking how often do we release testing channle updates once that channel has been established then we have a longer history on that front. It’s actually quite often at some points as we need folks feedback on real-world issues to honour the open source method.
But what you may want to consider is, if 4.1.0-0 works for you, you can of course use it indefinitely. All base os updates can be installed independant of update channel selection via the instructions here: Installation — Rockstor documentation
So you needn’t select any channel to keep all but the rockstor package updated.
And come the time the next installer is released it’s rpm will have been published in the testing channel so you could just update to that exact version. This is far easier that building from source via the instructions here:
And note that our default is to wipe all prior databases as we can only support migrating between rpm releases, hence the suggestion to stick with rpm installs. Also source releases consider any rpm release as an upgrade and they can’t co-exist as they live in different places but have the same database. We hope to work on flexibility in that area in time however.
If you look on the downloads page: https://rockstor.com/dls.html
under the following heading: Built on openSUSE Rpm: Install on Vanilla openSUSE/SuSE SLES
You can see more how we co-exist with our base OS. We are required to say and do some things to avoid ‘marks’ infringement but we are basically a couple of rpms, one trivially altered from upstream and one that is the rockstor rpm itself. Installed on a base openSUSE. Hence if the current stable rpm serves your needs, all other base OS updates can be applied by the regular means, and even from within our Web-UI.
My thoughts on how our current testing channel is going, with no rpm releases made just yet, is that it will be relatively short. And we have now a few fixes lined up for the current stable rpm, but I’d actually like to get folks onto the newer Django in the testing branch quite soon. But before that we must improve our testing suite which is my current rockstor-core repo task. https://github.com/rockstor/rockstor-core/issues/2384
Which in turn will help to ensure functional continuity between our releases.
However we have also had some work needed in updating our installer config in the following repo:
And that has taken some time but again is required as I’d like soon to release a new installer as each time an installer is build, using the instructions in this rockstor-installer repo, all base os updates are pre-installed which makes for smoother/faster setup. And we are due to do anther soon given it been months since our last downloadabel installers were build. But folks can always build their own of course, and customise them as they see fit.
I think the above update instructions should do you and when you fancy updating the rockstor rpm whenever one you fancy is release you can do that via the command line and specify it’s exact version from the testing channel. But do not just install the latest as that would likely break your system. The testing channel is just for developers and enthusiasts who want to help out with reporting issues/bugs or the like. It’s production use is basically zero unless it exactly coincides with the end of the testing channel where we copy that exact rpm over to the stable. The plan then is to cherry pick tested commits in testing to stable to fix-up issues there as we see fit. But likely only minor changes or important fixes given the backlog we have. And as stated we need to re-establish our next testing channel and it’s associated rpm releases. But that should be just around the corner.
Apologies but we have had so many large changes of late and some to come, that there is no way to answer this question. We now have the backend capability to release multiple testing rpms per day if need be. And I’d like to get to that scenario, but this latest Django update has changed almost all of our code and our historical record has set an expectation that every testing release is functional. This is simply unrealistic when both change OS and ALL base libraries while simultaneously extend our capabilities as folks request new features. And as we move forward with our own plans for updating how we dos stuff.
Hope that helps and I appreciate it’s a little bit of a waffle but we are a small team that is happy but not always able to be in all places at all times. I’m currently working on updating our installer config thought as we have drifted a little from upstream and have now to tweak a thing or two. All in good time however.