Another update profile "early adopter without Betas and RCs"

[yorick]

@Cyberpower678

I like to early adopt new releases

That’s called “General”. Waiting for absolute stability is called “Mission Critical”, and that can be seen on the Software Status page for CE users.

When you go to say 25.10.4 before it’s General, that’s essentially a beta test. With all the risks of a beta test. If it doesn’t have major issues, it’ll become General within weeks.

I’m increasingly worried about what this fourth option might do, particularly after seeing the response two above with all the bold text. It sounds like there’s an expectation that “released software” that’s not in “General” will have some level of stability. And while it often does, there’s absolutely no guarantee of that. If this option existed and users just upgraded without reading forums first, that’d be deploying foot guns. For “Early Adopter” it’s hopefully clear that it’s not safe in any way. But this fourth option, “Early Release Adopter”, is it also clear that it’s not safe in any way? I worry it might not be.

[Whiskydrinker]

@yorick

When you go to say 25.10.4 before it’s General, that’s essentially a beta test.

No, it’s a point release in which most people expect only bugs to get ironed out.

But my guess is that you also wait a few weeks after Debian or Ubuntu does a point release of their current stable. It’s a point release, so you must me careful. Screw the included security and functional fixes.

[Captain_Morgan]

@Glujaz

In this situation, Developer Profile makes no sense.

Developers get access to nightly builds…

[Captain_Morgan]

@Whiskydrinker

No, it’s a point release in which most people expect only bugs to get ironed out.

That’s a very idealized world where bug fixes never introduce new bugs.

TrueNAS integrates many upstream projects… each of which can have issues. We have to be more careful than that.

@yorick is correct… each new version has to be validated. Early adopters validate the new version and “general” users need to wait.

[yorick]

@Whiskydrinker

No, it’s a point release in which most people expect only bugs to get ironed out.

This is why I’m nervous about the fourth option. 25.10.4 can absolutely introduce regressions and bugs. It could cause a bonded NIC to fail, which means now you must have IPMI access or keyboard/monitor access to recover. Like happened with 25.10.2, after the General 25.10.1. It could cause apps to fail, or containers. It could have issues with SMB that break integration with macOS. The list is endless.

Anything that is below “General” is dangerous. And having a fourth option that suggests it is not is … well, dangerous.

[yorick]

@Whiskydrinker

But my guess is that you also wait a few weeks after Debian or Ubuntu does a point release of their current stable

At home? No. Because I don’t mind if something breaks.

When I oversaw a fleet of servers at work? You bet we waited. Docker CE also has releases, and they break now and then. Ubuntu kernel releases broke things, then a week later they fixed the breakage. This is not something you just want to have deployed automatically. Happily both Debian and Ubuntu have origin patterns for apt, like so:

Unattended-Upgrade::Origins-Pattern {
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
//        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

which is how you solve getting security fixes in production, while not breaking things.

And TrueNAS can’t do that. It literally can’t. It is created and deployed as an appliance, an entire image with everything. There’s no updating selectively via apt.

And that’s the trade off. You get the integration and “it just works” of an appliance, but you also only get the whole thing, not packages. In that way it’s like my Netgate/pfSense firewall: It too is an appliance and has early release access, but that’s not safe. Only when they call something stable, do I install it.

If you want faster iteration on individual packages then, well, you have to take the other side of the trade off: Don’t run an appliance. Run a base OS, with the packages you want on top. And then you can auto upgrade just for security releases, and do a feature upgrade manually every so often.

[jct]

I’m hearing that the selected terminology is not coming across as intended. To some degree that’s inevitable, but this case might actually be more acute than that.

And the penalty for guessing wrong is steep. We sometimes feel steered into a condition from which it’s difficult to recover. Here folks are being pointed at a special decoder page somewhere else, and told what they should have chosen in the first place. But they’re not being guided back on track.

Track. Maybe the train metaphor provides better guidance? There’s a main line, an express or bullet or red-eye… bah. It might not be there.

-=-

But clearly “early adopter” hasn’t conveyed what it should, to attract the desired subset. It’s teasing the prospect of early access; of special privilege; of sneak peek… From Which There Is No Return. If you’re looking to attract more testers and fewer lookie-loos, perhaps a better word is “experimental”.

Similarly: “developer” describes and calls out to an awful lot of power users. If what you mean is unstable nightlies, perhaps a better word is “incomplete”. Or, hell: “nightlies”.

“General” sounds generic and gray; intending default but sounding not recommended. And I haven’t seen this “mission critical” option presented to me. If one is GA and one is LTS, you could say so. You can’t call them mainstream vs conservative, but the “main line” train does appeal to me. It was hard to see 25.04.2.6 as a “current” while 25.10.2 came out as a “latest”.

In short: it would help a lot for the preferred option to sound the most appealing to the most people. We’re picking up handwavy dissonance when even an x.2 release seems disavowed by its parents. “Early” anything, with a non-complicated trail of integers, just sounds both clearer and more hopeful, and thus beckons the regular non-adventurers.

-=-

Please listen to @ReiKirishima about separating the concern of listing from the concern of scheduling. The system Updates page is a beautifully convenient place to spell out the secret decoder table — the entire secret decoder table. And to get people onto the right track for them.

It should be at least as easy to select “please let me know when this path comes of age so we can safely join it then” as it is to select “these future release notes sound like they might address my frustration of the moment; might as well give that one a try for now.”

Ratchet people toward where you want them. Don’t ratchet them away and get frustrated with them.

-=-

Most importantly: thank you. As confusing as the options may be, we’re lucky to have any of them.

[yorick]

@jct

perhaps a better word is “experimental”.

I can get behind that. Though to a degree that’s bike-shedding. “Early Adopter”, “General” and “Developer” always seemed clear to me. Maybe there’s widespread confusion and that’d warrant renaming the whole thing, but also even having a General train is brand-new, and having to choose is brand-new. Let people get to grips with it and choose “Manual release choice” as in “Early Adopter” or “Automated release choice” as in “General”, and then see whether it works out fine once people know it’s there and have made their choice.

[yorick]

@jct

And I haven’t seen this “mission critical” option presented to me.

Enterprise only. Mission Critical is something you can follow as a CE user by looking at the Status page and choosing the corresponding release, which previously was “General”. But it’s not a CE feature, by design. If you truly need Mission Critical, then the correct move is to buy Enterprise. If you’d like to follow Mission Critical releases but aren’t an Enterprise user, you can do so by manual effort. Trade-off of staying with the free edition.

[SmallBarky]

I think the current Trains are fine but there needs to be improvements on the Downloads page.

I think it needs to have only the Mission Critical and General Availability versions. Users could download and install either of those and they would be on the General train. They would only see ‘updates’ for the GA train. If a user wished to change trains, they would have to do so manually in the GUI and it would be on them to be a tester of the newer versions that are not in the GA train.

Another option would be to have the Mission Critical and General Availability downloads clearly marked and directly available, along with download options for Early Adopter (experimental) versions. This is a bit more risky as I think users would still download the ‘latest and greatest’ and then have issues with the updates offered by the system.

[yorick]

@SmallBarky

I think it needs to have only the Mission Critical and General Availability versions.

Yeah that’s a good point. The current download page makes it easy for users to deploy .

[jct]

Oh, in form it’s shameless bikeshedding. I’m with you. And I hope that doesn’t get out of hand. But it came up because stakeholders both inside and out are seeing real, empirical consequences.

Update profiles are a support concept, but they’re also UX and thus marketing. You want users to self-select into profiles that will satisfy them and bring them success. IMO, that takes some wordsmithing up front and a straightforward means of return to the happy path.

I was very excited this morning to finally be able to switch my in-laws up to the General profile! Before that, they were only shown two options: Developer and Early Access. No option in sight for simple release builds. Certainly not for the special blessed release builds that look to them exactly like all other release builds — those scary release builds which would get them in trouble if they came to the forums and admitted they were using them.

Your description of Mission Critical is multifaceted and intense, but helpful. IMO even knowing it exists would help casual users find and feel confident in their own Goldilocks profiles.

On the flip side: maybe they shouldn’t actually see nightlies unless they proactively start digging for more options. It shouldn’t be one of only two options — and should never have been the first option? Pure ; well said.

[yorick]

@jct

Before that, they were only shown two options: Developer and Early Access

Yeah that’s by design. One of the ix guys explained that elsewhere in the forum. So, say someone is on Early Adopter and they were able to choose General. Now they wouldn’t see interim releases until one was made General. But they may very well benefit from those interim releases, because they’re not on something stable yet.

This middle-of-the-road option - be on Early Adopter and choose General so you don’t see more Early Adopter releases - has its own complexities and trade-offs. And they decided that on balance, that would hurt more than it helps. I tend to agree.

A General, stable 25.10.3 is brand new. I’m really OK with allowing users to make the choice to be on General and see how it shook out a few months down the road.

[dan]

@yorick

“Early Adopter”, “General” and “Developer” always seemed clear to me.

They seem clear, but are they really? iX describes “Early Adopter” in-product as pre-release software:

Why then does it include every single real release (not pre-release) for at least some time, and many releases for their entire lifecycle? I don’t think iX wants us to think that 25.10.0 is actually 25.10-RC2, but that appears to be how they define “early adopter.”

[jct]

say someone is on Early Adopter and they were able to choose General. Now they wouldn’t see interim releases until one was made General.

I think that assumes one particular, surprising and unfortunate, least-effort implementation.

In fact I think it mistakes the challenge at hand with the more familiar task of picking from a menu of different products, such as CE vs Enterprise or even Core.

The system Update page tells a story and offers controls representing two separate concerns:

1. updating now
2. configuring notifications for the future

Consider 26b1 to be User A’s entrypoint on the directed graph. That fresh install, like all fresh installs, should default to the mainstream end user profile. The next mainstream step forward from 26b1 will be 26b2… and whatever rc’s up to 26.0, then 26.1, then 26.2, and 26.3…

User B’s entrypoint may have been 25.10.0. The next mainstream step forward from 25.10.0 was 25.10.1, then 25.10.2, then 25.10.3, then a long pause, then… maybe 26.3?

That’s the notification piece of it: the coaching; the blue button.

Now at some point during that long pause on 25.10.3, User B might voluntarily press a button to make the leap to 26.0. This is not a change in how they prefer to be notified going forward; they’re just intentionally jumping laterally across the directed graph to where User A is. They too expect that the next mainstream step forward from 26.0 will be to 26.1.

You guys will carefully decide what the next mainstream step forward from 25.10.3 should be. That might be the only case for which a “profile” is indisputably the proper tool for the job.

But from an installed 26.0? To be nudged toward anything other than 26.0.1, 26.1, or 27.0 would confuse/annoy/discourage us, and lead to the mismanaged expectations at hand.

For my in-laws with a 25.10.0 installation, urging them down into betas was not the right call.

[yorick]

@dan

Why then does it include every single real release (not pre-release) for at least some time

Because in reality they are RCs, but not labeled as such.

It’s a real release when it’s in General.

Before that, it’s a pre-release.

25.10.0: Was an RC
25.10.1: Was an RC, until it moved to General
25.10.2: Was an RC
25.10.3: Was an RC, until it moved to General

Not actually labeling them as RCs and then removing the label after a soak test is confusing, agreed.

So, if we’re bike shedding: How about “Pre-Release” and “Stable” instead of “Early Adopter” and “General”?

And change the Download page to show “Stable” and “Mission Critical” by default, with “Pre-Release” and “Nightly” behind a “here be dragons” additional click.

Actually calling the pre-releases pre-releases, like in their actual version string, instead of relying on the software status page, would be a nice bonus.

@jct Yep your in-laws shouldn’t be on beta. And, there never was a “General” train before 25.10. Stick them on it on 25.10.3, and tell them not to touch that particular selection because it’s an ix word for “Stable”

[jct]

@yorick Heh. Thanks. Yeah, they’re good. I’d bumped them to Goldeye because of containers.

I can’t find it at the moment, but I recently read a reply to someone who’d done that too — but they skipped a generation to do it. The reply to that person explained marvelously well why skipping fish was unsupported and ill-advised.

This strikes me as another argument in favor of a directed graph model, instead of a filtered timeline or tagged end state model. The mainstream path forward from Electric Eel would be to Fangtooth, which could then safely and immediately suggest Goldeye, and so on.

25.10.3 may be the one true “General” release of record right now — but it’s not for them. Yet.

Out here, we’re not thinking production branches. We’re thinking what’s best for me from here.

And I think it’s super cool that there might be more than one answer at a given moment: coast along as/when prompted, or go look and click to embrace the near future on my own schedule. Either way, the lesser resistance would naturally keep steering me back on track, not off.

there never was a “General” train before 25.10.

Understand: from our perspective, there never was a “General” train before 3AM Sunday.

[yorick]

@jct

there never was a “General” train before 3AM Sunday

Absolutely true. It’s a brand-new feature. That’s why I’d like to see how it works out once users realize it’s there and switch to the General aka “Stable” train.

[dan]

@yorick

Because in reality they are RCs, but not labeled as such.

…which returns us to the real issue, which is and has been iX’ release practices. The software status page and now the update trains are just ways of attempting to paper over the fundamental problem of iX “releasing” software that just isn’t ready.

[yorick]

@dan

to paper over the fundamental problem of iX “releasing” software that just isn’t ready

That’s likely deliberate. That doesn’t happen on Enterprise. “Mission Critical” as the default, and “General” aka “Stable” as the second yolo option.

CE is where bugs are found that ix doesn’t find. That’s the contract - ix provide software for free; users of the free software find and report bugs. And are passionate about it.

It’s a tradeoff and I’m ok with it, particularly now that a “Stable” train is available.