The current cadence for major TrueNAS versions appears to be every six months now. Am I the only one that would rather this be at max every year? Genuinely curious if I’m just too slow and conservative?
2 Likes
You don’t use Arch btw?
5 Likes
No. I’d rather they not be on any set schedule at all, actually–set a roadmap based on features, and release when it’s ready. A release with “experimental” features should never happen.
14 Likes
The 6 months or timeline doesn’t really bother me, so long as the updates are meaningful and not introducing tons of new issues - like Fangtooth does (mainly referring to the changes to Virtual Machines). In that case, I would’ve much rather had it be a year (or any amount of time until the feature was ready) and have those things more thought and fleshed out.
1 Like
Tell that to Ubuntu also. I had to ditch Ubuntu a while back as my daily desktop driver because their “package version freeze window” was completely arbitrary, based on the “every 6 months” cycle. You had to get lucky that the software you’re using, which is available in their repos, included the upstream bugfixes before they froze everything.
This leaves you with applications that contain known bugs which you’ll be stuck with until the next major Ubuntu version[1] or if you can find a third-party PPA.
There are exceptions, like Firefox, but my point still stands. ↩︎
2 Likes
I somewhat agree, but haven’t noticed as many issues with them. I typically only use LTS releases of Ubuntu though.
This specific problem is one I mentioned long time ago when SCALE was released.
The issue is that Linux drivers are specific to the KERNEL. If you wait a year or more, any new driver updates, GPU, network, etc… end up being static until then. In the mean time users complain that their new fancy widget do-hicky does not work. Even with a 6 month release schedule for SCALE, we get plenty of people wanting updated drivers.
You think updates every 6 months is too often?
I do Gentoo Linux updates every 2 to 4 weeks, on 4 computers, year after year. The only saving grace is ZFS alternate boot environments means if it goes wrong, I can back out with a simple reboot.
4 Likes
The existing versioning scheme takes into account users who want a less frequent update schedule, it is recommended that they stick to the Mission Critical releases.
Mission Critical Mature software that enables 24 x 7 operations with high availability for a very clearly defined use case. Software updates are very infrequent and based on need.
The new Update Trains are going to be based on User Type and not major release.
4 Likes
Arguably… what matters less is the actual frequency, and what matters more are the principles of what determines a release when it happens. Or put differently - as a user, you could decide to update once yearly as opposed to every six months, seemingly more conservative…? But in practice that won’t help - per recent history, if that yearly update would have coincided with Fangtooth (25.04), you would still have ended up with broken VMs and numerous other issues as exemplified in other recent threads. There is nothing more intrinsically stable about a less frequent release schedule until iX makes it so, by prioritising stability of the core product over new and experimental features.
1 Like
I thought everyone just used the LTS versions?
1 Like
…and while they aren’t quite as bad as Nextcloud at this, I don’t know they’re too far behind.
That doesn’t help with the issue of using Ubuntu as a daily desktop driver for this reason:
The latest Ubuntu LTS is 24.04 “Noble Numbat”. The version of Smb4K on its repos is 3.2.5, and it will never be updated. (The latest upstream version is 4.0.2.)
Desktop users on the latest Ubuntu LTS will be stuck with an old buggy version of Smb4K because of the distro’s “package version freeze policy”.
On Arch and Arch-based distros, I’m happily using Smb4K 4.0.2 and benefit from its upstream updates as they arrive.
This is just one example.
It happened to me often enough with different applications that I had to ditch Ubuntu as a daily desktop and switch to a rolling release distro.
EDIT: I understand this isn’t as important or relevant to servers and NASes. Just sharing my opinion about Linux distros for daily desktop usage.
1 Like
There are a lot of good points for every 6 months and completed features schedule. But every 6 months is only for a name change/major version, they actually update as needed using the .1 or .2 versioning (25.04.1). Very important or critical updates do occur. Just to add a new feature waits for the 6 month routine to get it.
The team at iXsystems these days are doing one hell of a good job. All who have been here a while remember version 10. I think they were trying to meet a schedule and just pushed out what they had, which wasn’t well tested and everyone paid in pain. In the end, if iXsystems is able to push out good solid and stable updates, that is the most important factor to me.
As for someone wanting the latest drivers, they may want to look into building TrueNAS themselves and then they can add those drivers. Will it be easy? not at first if you haven’t done this before, but after you 20th build, you will be comfortable. I would say to write down each step so you do not forget a step.
4 Likes
This is a great point. Pardon my ignorance though, but could they not update the kernel with minimal changes to everything else? I wouldn’t have thought kernel updates had many breaking changes.
I’m over here winking from Garuda Linux as my desktop. Daily updates, I just see how many. More than 50, let’s go!
1 Like
I think its fair to say that the worst breaking changes tend to come from the kernel updates.
3 Likes
I dont really see problem with once every 6 months major version.
If I dont like any particular release like 25.04 I can just skip it and stay on 24.10 until 25.10. Nobody forces me to update.
On the other hand I dont see any reason why people shouldnt have the choice to update to 25.04 if it works for them. Why should they be forced to wait whole year if iX can make major releases every 6 months?
And about “when its ready” approach. Regularity is often important, at least in business. Being able to reliably know that every 6 months there is major release is convenient.
Otherwise there would be just constant asking “when will be next major version ready” and people couldn’t plan their updates into the future because they wouldnt know when they will release.
2 Likes
I can’t agree here.
Sure, it could be worse, and iX did the right thing in putting it out of its (and our) misery. And yes, they’ve improved since then, though that bar is on the floor and you’d need a shovel to get under it.
They are–we just don’t know which ones they will be. Nor do users know what those releases might break. What’s important is that they’re able to consistently push out good and stable updates, and I don’t think that’s been shown–rather to the contrary, I believe.
“So just stay on 24.10,” some people say. But there are a few problems with that plan:
- iX aggressively EOLs earlier releases.
- It’s rare to see so much as a point release for any version prior to the current major release, and it’s unpredictable whether and when these will occur. If you want security patches and bug fixes, you’d better be on the current release.
- Why they then recommend an unsupported release for “general use” on their software status page is a mystery.
- iX’ promises of extended support (when they make them) can’t be trusted.
- Shortly before the release of 24.10, iX uncharacteristically announced that 24.04 would be supported for at least a year following the release of 24.10. But as we saw earlier this year, that promise carried a hidden caveat that app migration would stop working after June 1 of this year. And we’ve already seen at least one user here who was bitten by this.
- iX’ messaging is decidedly mixed.
- Their software status page, linked up-thread, doesn’t (at this writing) recommend 25.04.1 for anybody, and recommends the 25 series in its entirety only for early adopters and testers. Morgan says 25.04.1 is appropriate for Enterprise use. Which is it? Their answer is word salad.
We’re having this conversation now, I think, because 25.04 removed a virtualization function that was deemed production-ready[1] and replaced it with one that’s marked as “experimental,” obnoxiously reminding you of that fact every time you click anything in that part of the UI. That’s a fail, and that’s obvious to everyone but iX, but it isn’t the first time they’ve done something like this, and I doubt it will be the last.
As I said above, I don’t really care about the schedule as such; what I want is software I can trust. iX aren’t providing that. What’s saving them is that everyone else is even worse.
TrueNAS virtualization features have never been anything like production-ready and I doubt they ever will be. ↩︎
6 Likes
I still trust CORE 13.0-U6.7… 
3 Likes
Yeah this is kind of what I was getting at.
Practically speaking I build new systems essentially every year and put them into production for 5-6 years. Very boring large scale SMB/NFS file shares. Once they are in and working ideally I’d like to play with them as little as possible. Naturally I want them to remain secure and fix any terrible bugs that are found but outside of that Im happy to just let them tick along missing all the cool new toys for now.
I may be alone in this thinking but I would guess not. With every update there its a risk to the service and with every major update that risk is increased and I have seen this firsthand over the years.
I may be asking for the impossible but I would like to have the option to sit on a version for an extended period of time (as long a feasibly possible perhaps 5 years like other LTS) but still maintain a good level of security. Even if only 2-3 years that would be better than the current situation.
Perhaps iX could update their ‘Software Status’ pages with EOL dates for each version so users can make better educated decisions?
1 Like