@dkozel I'd like to put some design work forward for this notification. To make sure I understand correctly, are these 2 possible scenarios?

1. Old-to-new
Bob the radio-astronomer has a grc file, black-hole.grc, that he's created on his old-trusty radio-astronomy rig which is running a GNU Radio 3.1. (In the file header it'll mention GNU Radio version=3.1)

Bob's old-trusty rig dies and he upgrades to newer hardware. He now wants to run the GRC file on his new rig which is running a GNU Radio 4.0.

When he opens the grc file (created on GR 3.1) on his new rig (running GR 4.0), this notification will be displayed. (correct?)

The purpose of the proposed notification is to tell him that the GRC file was written in a much older Gnuradio version. Because of this, the GRC behaviour might not be what he expects.

2. New-to-old

Bob the radio-astronomer has a grc file, black-hole.grc, that he's created on his desktop machine using GRC 4.0.

(In the file header it'll mention GNU Radio version=4.0)

Bob wants to run his GRC file on his old-trusty radio-astronomy rig which is running a GNU Radio 3.1.

When he opens the grc file on his 3.1 rig, this notification will be displayed.

The purpose of the proposed notification is to tell him that the GRC file was written in a much older or newer Gnuradio version. Because of this, the GRC behaviour might not be what he expects.

Is that correct?

I've got some questions to understand better:

• do we know what Bob's expectations are when he opens the file in the older/newer GRC version?
• is there any advice for users if this happens? e.g. Upgrade the grc version? Use older blocks? Or just "be aware"?
• are there any ideas what those possible behaviours might be, or be localised to? e.g. filters, math calculations?
• is there a way for them to verify if the behaviour is as expected. i.e. I'm guessing there's not a checksum
• are there particular logs/outputs they should check to verify it's working/or not as it should?

A good usability heuristic when dealing with errors - helping users recognise, diagnose and recover from them is "Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution."

When I worked on the pip project, we faced a similar issue providing solution advice where users ran into dependency resolution problems. Due to the complexity, we couldn't tell the user the exact cause of the conflict but we did provide them with some possible solutions.

In order to indicate the problem and suggest a solution, I'm trying to list the most possible causes of these "possible changes in behavior" of grc files, and how to solve them (if known).

Causes for possible change in grc file behaviour

So far I've got, the grc file:

contains core block(s) that have been removed from this version of GRC
Possible fix: use replacement blocks (maybe block X, Y, Z)

contains core block(s) that didn't exist on this version of GRC
Possible fix: use replacement blocks (maybe block X, Y, Z)

contains block(s) from OOT module(s) that are not installed
Possible fix: install OOT module D

interfaces on block(s) have changed
Possible fix: redesign flowgraph to account for different i/fs

Can anyone help with other possible causes? And sense check my possible fix suggestions. @dkozel @mormj. Others?