Initialize a Default Build Type for ROG and TUF

[ExtremeFiretop]

@Martinski4GitHub

How do we feel about this solution?

In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

[Martinski4GitHub]

@Martinski4GitHub

How do we feel about this solution?

In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?

IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.

I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

[ExtremeFiretop]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?

IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.

I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

[ExtremeFiretop]

IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.

I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

We could do this, but it would populate the setting in the settings file even if the firmware doesn't have a ROG build. Which means the option would be displayed in the WebUI even if the firmware doesn't have an option available.

At least with the current method.

[Martinski4GitHub]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?
IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.
I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

Ah, OK. So the code offers the option to select the ROG build type only if we know in advance that the F/W is going to be available, at some point in the future, from that branch.

What about if in 3 or 4 months, RMerlin decides to offer the ROG builds for some routers on the 3006 branch?
Or, if Gnuton decides to drop the ROG build types for some routers?

Yes, we can easily change the code at that time to accommodate those decisions, but I'd prefer if the code does not rely on some arbitrary decision that we have to know in advance.

What about if for the ROG routers that option is offered and always available but the messaging is changed to indicate that when selecting the "ROG" build type, it takes effect ONLY IF and WHEN the F/W image for ROG WebGUI is actually available; otherwise, it falls back to the "Pure" standard build?

This way the code does not rely on the ROG build type always being available (or not) at some future point.

[ExtremeFiretop]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?
IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.
I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

Ah, OK. So the code offers the option to select the ROG build type only if we know in advance that the F/W is going to be available, at some point in the future, from that branch.

What about if in 3 or 4 months, RMerlin decides to offer the ROG builds for some routers on the 3006 branch? Or, if Gnuton decides to drop the ROG build types for some routers?

Yes, we can easily change the code at that time to accommodate those decisions, but I'd prefer if the code does not rely on some arbitrary decision that we have to know in advance.

What about if for the ROG routers that option is offered and always available but the messaging is changed to indicate that when selecting the "ROG" build type, it takes effect ONLY IF and WHEN the F/W image for ROG WebGUI is actually available; otherwise, it falls back to the "Pure" standard build?

This way the code does not rely on the ROG build type always being available (or not) at some future point.

It's actually not a bad idea, it's not something I considered but you have basically outlined why currently i follow the changelogs on new firmware releases, so that I can know ahead of time when these types of changes happen so we could modify the code in the script accordingly.

What your suggesting (if I understand correctly, and please correct anything wrong)

Is that we just forget the logic on when to display it, and instead, display the options all the time for GT models or TUF models, but instead change the messaging so that even if they select a ROG build in the settings, and non is available, it will default to pure (which is the current logic, nothing would need to be changed there)

All we would need to do is change the messaging, and drop the firmware requirements.

[Martinski4GitHub]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?
IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.
I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

Ah, OK. So the code offers the option to select the ROG build type only if we know in advance that the F/W is going to be available, at some point in the future, from that branch.
What about if in 3 or 4 months, RMerlin decides to offer the ROG builds for some routers on the 3006 branch? Or, if Gnuton decides to drop the ROG build types for some routers?
Yes, we can easily change the code at that time to accommodate those decisions, but I'd prefer if the code does not rely on some arbitrary decision that we have to know in advance.
What about if for the ROG routers that option is offered and always available but the messaging is changed to indicate that when selecting the "ROG" build type, it takes effect ONLY IF and WHEN the F/W image for ROG WebGUI is actually available; otherwise, it falls back to the "Pure" standard build?
This way the code does not rely on the ROG build type always being available (or not) at some future point.

It's actually not a bad idea, it's not something I considered but you have basically outlined why currently i follow the changelogs on new firmware releases, so that I can know ahead of time when these types of changes happen so we could modify the code in the script accordingly.

What your suggesting (if I understand correctly, and please correct anything wrong)

Is that we just forget the logic on when to display it, and instead, display the options all the time for GT models or TUF models, but instead change the messaging so that even if they select a ROG build in the settings, and non is available, it will default to pure (which is the current logic, nothing would need to be changed there)

Yes, exactly. The option is always available regardless of any future decision by the F/W developers on whether to support the ROG build type on some specific branch.

All we would need to do is change the messaging, and drop the firmware requirements.

OK, good. That would make the changes nice & simple to implement and then test & validate.
This way we don't have to keep chasing whatever F/W build decisions will be made in the future.

[ExtremeFiretop]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?
IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.
I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

Ah, OK. So the code offers the option to select the ROG build type only if we know in advance that the F/W is going to be available, at some point in the future, from that branch.
What about if in 3 or 4 months, RMerlin decides to offer the ROG builds for some routers on the 3006 branch? Or, if Gnuton decides to drop the ROG build types for some routers?
Yes, we can easily change the code at that time to accommodate those decisions, but I'd prefer if the code does not rely on some arbitrary decision that we have to know in advance.
What about if for the ROG routers that option is offered and always available but the messaging is changed to indicate that when selecting the "ROG" build type, it takes effect ONLY IF and WHEN the F/W image for ROG WebGUI is actually available; otherwise, it falls back to the "Pure" standard build?
This way the code does not rely on the ROG build type always being available (or not) at some future point.

It's actually not a bad idea, it's not something I considered but you have basically outlined why currently i follow the changelogs on new firmware releases, so that I can know ahead of time when these types of changes happen so we could modify the code in the script accordingly.
What your suggesting (if I understand correctly, and please correct anything wrong)
Is that we just forget the logic on when to display it, and instead, display the options all the time for GT models or TUF models, but instead change the messaging so that even if they select a ROG build in the settings, and non is available, it will default to pure (which is the current logic, nothing would need to be changed there)

Yes, exactly. The option is always available regardless of any future decision by the F/W developers on whether to support the ROG build type on some specific branch.

All we would need to do is change the messaging, and drop the firmware requirements.

OK, good. That would make the changes nice & simple to implement and then test & validate. This way we don't have to keep chasing whatever F/W build decisions will be made in the future.

Sounds like a good option, and would require less "maintenance" to upkeep as you mentioned.

I'll work on this tomorrow, just heading off to bed now. Thanks for the idea @Martinski4GitHub !

[Martinski4GitHub]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?
IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.
I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

Ah, OK. So the code offers the option to select the ROG build type only if we know in advance that the F/W is going to be available, at some point in the future, from that branch.
What about if in 3 or 4 months, RMerlin decides to offer the ROG builds for some routers on the 3006 branch? Or, if Gnuton decides to drop the ROG build types for some routers?
Yes, we can easily change the code at that time to accommodate those decisions, but I'd prefer if the code does not rely on some arbitrary decision that we have to know in advance.
What about if for the ROG routers that option is offered and always available but the messaging is changed to indicate that when selecting the "ROG" build type, it takes effect ONLY IF and WHEN the F/W image for ROG WebGUI is actually available; otherwise, it falls back to the "Pure" standard build?
This way the code does not rely on the ROG build type always being available (or not) at some future point.

It's actually not a bad idea, it's not something I considered but you have basically outlined why currently i follow the changelogs on new firmware releases, so that I can know ahead of time when these types of changes happen so we could modify the code in the script accordingly.
What your suggesting (if I understand correctly, and please correct anything wrong)
Is that we just forget the logic on when to display it, and instead, display the options all the time for GT models or TUF models, but instead change the messaging so that even if they select a ROG build in the settings, and non is available, it will default to pure (which is the current logic, nothing would need to be changed there)

Yes, exactly. The option is always available regardless of any future decision by the F/W developers on whether to support the ROG build type on some specific branch.

All we would need to do is change the messaging, and drop the firmware requirements.

OK, good. That would make the changes nice & simple to implement and then test & validate. This way we don't have to keep chasing whatever F/W build decisions will be made in the future.

Sounds like a good option, and would require less "maintenance" to upkeep as you mentioned.

I'll work on this tomorrow, just heading off to bed now. Thanks for the idea @Martinski4GitHub !

You're welcome. Have a good night's sleep, bud.

[ExtremeFiretop]

@Martinski4GitHub
How do we feel about this solution?
In short, we just pick a default firmware type going forwards, it will always be pure firmware (not rog or TUF) by default unless otherwise specified.

The decision to make the "Pure" build type (AKA "Standard" Merlin WebGUI) always the default type is very sound; however, in the code for the "ROG" built type, you're also checking for the F/W installed base branch (3004 or 3006). What's the reason for these specific checks?
IMO, the default build type "Pure" should be set regardless of the F/W base branch because this default is independent of whether the base branch currently offers the ROG builds (and perhaps in the future, there might be a "ROG" build). Once the default is set, the user will have the choice to select ROG if and when available on whatever base branch the router F/W is coming from.
I think the logic should be something simpler like this:

  if echo "$PRODUCT_ID" | grep -q "^TUF-"
  then
      if [ "$(Get_Custom_Setting "TUFBuild")" = "TBD" ]
      then Update_Custom_Settings "TUFBuild" "DISABLED"
      fi
  elif echo "$PRODUCT_ID" | grep -q "^GT-"
  then
      if [ "$(Get_Custom_Setting "ROGBuild")" = "TBD" ]
      then Update_Custom_Settings "ROGBuild" "DISABLED"
      fi
  fi

My 2 cents.

Currently the logic around line: 10135 (wow btw) to display the build type uses this reasoning; so I was following that more or less found below:

           bt) if echo "$PRODUCT_ID" | grep -q "^TUF-"
               then _ChangeBuildType_TUF_
               elif [ "$fwInstalledBaseVers" -le 3004 ] && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               elif [ "$fwInstalledBaseVers" -ge 3006 ] && "$isGNUtonFW" && \
                    echo "$PRODUCT_ID" | grep -q "^GT-"
               then _ChangeBuildType_ROG_
               else _InvalidMenuSelection_
               fi
               ;;

I guess the the real answer to your question is because GT- models (RMerlin) don't support ROG builds outside of 3004 firmware anyways. While TUF builds are supported on all firmware versions, and Gnuton only supports GT (ROG) models in 3006 and above.

Ah, OK. So the code offers the option to select the ROG build type only if we know in advance that the F/W is going to be available, at some point in the future, from that branch.
What about if in 3 or 4 months, RMerlin decides to offer the ROG builds for some routers on the 3006 branch? Or, if Gnuton decides to drop the ROG build types for some routers?
Yes, we can easily change the code at that time to accommodate those decisions, but I'd prefer if the code does not rely on some arbitrary decision that we have to know in advance.
What about if for the ROG routers that option is offered and always available but the messaging is changed to indicate that when selecting the "ROG" build type, it takes effect ONLY IF and WHEN the F/W image for ROG WebGUI is actually available; otherwise, it falls back to the "Pure" standard build?
This way the code does not rely on the ROG build type always being available (or not) at some future point.

It's actually not a bad idea, it's not something I considered but you have basically outlined why currently i follow the changelogs on new firmware releases, so that I can know ahead of time when these types of changes happen so we could modify the code in the script accordingly.
What your suggesting (if I understand correctly, and please correct anything wrong)
Is that we just forget the logic on when to display it, and instead, display the options all the time for GT models or TUF models, but instead change the messaging so that even if they select a ROG build in the settings, and non is available, it will default to pure (which is the current logic, nothing would need to be changed there)

Yes, exactly. The option is always available regardless of any future decision by the F/W developers on whether to support the ROG build type on some specific branch.

All we would need to do is change the messaging, and drop the firmware requirements.

OK, good. That would make the changes nice & simple to implement and then test & validate. This way we don't have to keep chasing whatever F/W build decisions will be made in the future.

Sounds like a good option, and would require less "maintenance" to upkeep as you mentioned.
I'll work on this tomorrow, just heading off to bed now. Thanks for the idea @Martinski4GitHub !

You're welcome. Have a good night's sleep, bud.

I suck at sleep, just laying here on my phone. Hahaha! Goodnight bud

[ExtremeFiretop]

@Martinski4GitHub

Completed as requested in commit: 7fed3e1

:)

[ExtremeFiretop]

@Martinski4GitHub

Did some changes to the WebUI to match the changes in the core shell script.
Here is the final result in the shell script:

And the results in the WebUI when changing the option:

And if the option is selected:

[Martinski4GitHub]

@Martinski4GitHub

Did some changes to the WebUI to match the changes in the core shell script. Here is the final result in the shell script:

And the results in the WebUI when changing the option:

And if the option is selected:

Sorry, bud; I was very busy all Sunday evening. Anyway, it's looking very good; but I'm tired & sleepy at the moment to do a proper code review so I'll do it Monday evening for sure.

Take care and have a good night, bud.

[ExtremeFiretop]

@Martinski4GitHub
Did some changes to the WebUI to match the changes in the core shell script. Here is the final result in the shell script:

And the results in the WebUI when changing the option:

And if the option is selected:

Sorry, bud; I was very busy all Sunday evening. Anyway, it's looking very good; but I'm tired & sleepy at the moment to do a proper code review so I'll do it Monday evening for sure.

Take care and have a good night, bud.

No rush, review when your in the mood. Else it starts to feel like work, it's only fun when you do it on your own time and ambition.

PR will still be here when your ready, enjoy the night bud!

[Martinski4GitHub]

Approved!