Accepted Preview Plan

What exactly does this function do?
I was in doubt and neither the router nor the FAQ has a more detailed explanation.

“Enable the switch to get latest unstable updates, patches, improvements, and enhancements as soon as they’re available. Set it once and it stays on (you always have the option to turn it off later)”

yes I know that lol, I read it on the router, I say if it is related to packages? updates? or something that is not mentioned?

AFAIK it means that it will install the latest Beta firmware versions on the router.



IMO this should really read as ‘Accept Beta versions’ … preview can also imply a ‘sampling’ in limited scope. I think the general population understands the software concept of beta.

/ 0.02USD

Preview Plan = rc. ie. release candidate version. which is between stable and beta version.

1 Like

A ‘plan’, in Western parlance, implies a subscription & fee… like a mobile phone ‘plan.’

Thanks for the suggestions. We will change the wording ASAP.

1 Like

The feature aims to introduce a firmware version as a release candidate to a limited number of users for one-month testing before it becomes a stable firmware. If a user dares to install this version of the firmware, they will need to take the risk of encountering bugs, as it has not been formally released. Once the version is officially released, users won’t need to take any further action to install it again.
From user perspective, which one is the best phrase:

  • “Allow release candidate”
  • “Preview release candidate”
  • “Join insider preview update program”
  • “Accepted preview plan”

0 voters

Install release candidate’ — with further notice all settings, packages, confs, etc. will be erased/over-written without confirmation.

You don’t want a repeat of that whole automatic upgrade fiasco a few months ago after all.

I would of suggested “Join the preview program”, since it’s simple and easy to understand.

But instead of a checkbox to join a preview program, why not display a dropdown menu that allows people to pick the firmware type? You already have stable, release candidate and beta branches. And it’d be nice if you could get snapshots working for the GL-MT6000 like you do for the original Flint.

And I’ve seen some people complain about their installed packages going missing after they perform firmware updates, so why not offer an alternative to luci-app-attendedsysupgrade?

1 Like

… or just directly call it fr the GL GUI in some fashion. Here’s what I have in a bash alias:

sysupgrade -b "/root/backup/tarballs/backup-${HOSTNAME}-$(cat /sys/class/net/eth0/address | tr '[:lower:]' '[:upper:]' | tr -d ':')-$(date).tar.gz"

But that still won’t answer the question of installed ipkgs. Perhaps GL should adapt:

In any case, there should be an info text about what firmware will be installed and that it’s RC and not nightly or beta.

Here are my thoughts about the possibilities:

  • Allow release candidate → “Allowing” does not sound like “Install it now”, it’s more like choosing the firmware branch.
  • Preview release candidate → “Preview” sounds to me more beta than RC (even if there is a mention of “release candidate” later)
  • Join insider preview update program → Sounds totally “nightly” for me, thanks to Windows :smile:
  • Accepted preview plan → Same like 1st option

Since it’s only about RC, I would simply prefer something like “Opt-in for release candidate firmware” or sth like that. My biggest problem with the descriptions: The basic possibility to provide feedback is missing. This option should generally only be used by people who know what they are doing. You have to emphasize that somehow.

In the long run, I would like to see a dropdown where you can select the firmware update channel between stable, RC, beta and snapshot

1 Like

Well, if they’re targeting the average home user then I don’t think it should be up to the user to create that backup. Instead the router could automatically save a list of user installed packages and then it should automatically reinstall them after a firmware upgrades completed.

Personally I like the luci-app-attendedsysupgrade method, since it builds you a custom image and it’ll be served to others if they use the same packages.

That’s what I’m saying; all of this can be ‘automated’ w/ some script(s). GL already has far more complex scripts in use. Putting aside 512 or 256 KB for a tarball shouldn’t be much, if any of, an issue. Get it all done in the GL GUI.

… & I’ve got far more than just GL stock on my Slate AX, Flint v1.

This is something we want to do. Currently, we plan to allow limited users to test the release candidate and report potential bugs before formally releasing it as a stable version. Ideally, we want users who understand the risks to use the release candidate. Installation will not be automatic; in other words, with your permission, we can push this version to you, and you will need to install it manually.

1 Like