The data disagrees with you in the sense that we look at number of bug reports vs the number of users. We have seen declining bug reports with increasing user counts.
However, we agree that users should be reluctant to trust RC.1. That is why we started publishing the software status page.
Unless you consider yourself an “early adopter” and have the relevant skills, do not use RC.1. However, we do appreciate early adopters and bug reports. They help us polish the stone for subsequent versions.
If RC1 quality is not sufficient and we don’t get enough testing, then RC2 is the logical choice for us to use.
The last 24.10 version has had both record adoption in a short period and relatively few bug reports. We got to a high quality level across a hugely diverse set of use cases and build configurations with just 2 updates.
I’m not inclined to ask to fix a working process. If the release notes or software status page are misleading and causing issues… then we’d like to fix that.
That’s also true for Linux, the kernel. When there are no more feature additions, it’s labeled rc1. Then it goes through multiple rcN until Linus thinks there aren’t any critical or obvious bugs left; and then it’s released.
If it’s good enough for the kernel …
The software release guidance (software status page) is a good one. In a nutshell, if you like testing, do beta or rc; if you don’t mind there still being some bugs, try the GA; and if you want to adopt things when they’re very solid, that’s usually around .2 or .3.
Holds for TrueNAS, PostgreSQL, Linux kernel, and so many others.
I’m more than OK with TrueNAS releasing “the TrueNAS way”. There’s no one true standard for labeling; and TrueNAS has been releasing remarkably stable software lately.
The data interpretations are up for debate. It might be that when more regular users are joining in at RC.1 they are less likely to report bugs than developers and testers.
I still believe that just 2 public test versions (BETA.1 + RC.1) is a bit on the shy side. Last round with EE RC.1 was quite broken and needed a quick fix to RC.2. Dragonfish was a bit more smooth.
This is me giving my 2 cents on it. I appreciate the posts made above by the community pitching in. And the responses given by the IX team.
Looking forward to full release of Fang Tooth and hopefully meaningful improvements to the instances tab.
An easier way to mount an iso with the virtio drivers like with the previous system
Easier to glance (working) metrics reporting similar to the apps page
Would be my two requests. But I guess I should better post that in the RC.1 thread.
For “instances” we have been clear it is “experimental” in this release… perhaps that confusion is why you were think we should not call it RC.1
Most TrueNAS users (and nearly all paying customers) don’t rely on instances and hence we treat them orthogonally.
We aim to improve Instances and learn during Fangtooth. They will be non-experimental in GoldEye. We will keep the community up to date on any issues through the release notes.
Heh, I somehow made the judgment that stable releases of the software were ready to jump on. I guess it’s better to wait for .1 or later. Or possibly wait for a different release cycle and just upgrade through the previous one at the same time.
I guess I’m used to flying by the seat of my pants. I also tend to wonder why more Apple developers don’t immediately jump into the developer betas the instant they launch and get their software ready first thing, instead of waiting for a .1 or .2 of the “release” version.
Then again, I guess maybe they don’t want to dogfood it on their personal development machines. I know I didn’t the last release cycle, so I guess maybe I’m slowing down in my “old” age. I still install the final .0 on day one, or possibly even the release candidate a few days early, though.
The release quality for my own software is awful. I just push a release when I think I’ve finished something, and quickly follow it up with yet another release if I found out soon enough that I broke something in the process. I’m probably a perpetual disappointment of breakages to my maybe 100-300 users, going by the number of unique installs reporting timing data for their playlist imports. I try not to scare people away, but alas, it’s hard when I don’t do any preview testing other than my own personal use of the app.
The worst thing that’s happened from this is that one user found the “Trash selected track(s)” feature can permanently delete files, if they use it on files that can’t be trashed. Thanks, Apple, for making that API unsafe!
I find it weird that major release versions would have ‘experimental’ features while discarding the old stable parts they replace to be finalized in the next major version by design. That’s indeed where my confusion mostly comes from. And I was not aware that there was still so little interest from enterprise for the virtualization side of things. Thanks for that explanation
I do wonder though if this 2 major versions per year release cadence with both having unfinished features is really the way forward though? It would mean that nowhere during the year the software would be feature complete and fully stable. At least if I understand it right that features are going to be introduced in one version and only finished in the next. That seems like an never ending story of unfinished features and not a stable point in the year that conservative users can rely on to use to jump from to the next.
Goldeye could have other new features introduced to be finalized in the next major release after?
Or am I misunderstanding the release cadence? Because if I do understand it correctly then technically all community builds would realistically be BETAs. And possibly never fully feature complete disregarding .0 .1 .2 versioning.
There will NEVER be a feature complete version of TrueNAS.
Our aspiration is reliable and usable with few outstanding bugs.
We have many years of new features we’d like to add.
Entrpririses do want VMs, but they also need many more features. HA, VM mobility, migration to/from VMware. We don’t market a capability if it doesn’t meet the needs.
