Default Boot version always selected by default

[onobc]

Steps to reproduce

1. Fresh SCDF 2.11.0 install
2. Register task2 apps

   task.timestamp=maven://io.spring:timestamp-task:2.0.2
   task.timestamp.bootVersion=2
   task.timestamp-batch=maven://io.spring:timestamp-batch-task:2.0.2
   task.timestamp-batch.bootVersion=2
   

3. Register task3 apps

   task.timestamp=maven://io.spring:timestamp-task:3.0.0
   task.timestamp.bootVersion=3
   task.timestamp-batch=maven://io.spring:timestamp-batch-task:3.0.0
   task.timestamp-batch.bootVersion=3
   

4. Make task3 apps the default (manage versions view)
5. Create simple timestamp task definition timestamp w/ name "taskOne"
6. Choose launch task
7. In launch view notice the default version is pre-selected. Now click the drop-down Application Properties -> Version and select the boot2 task version
8. Click "Launch Task"
9. VERIFY: In task execution view that is shown, prefixes must be BOOT2
10. Select "Relaunch Task"
11. PROBLEM: In launch view, notice the default version (boot3) is selected eventhough task was previously launched w/ boot2.

This forces the user to re-specify which version of task app they want to use on each invocation (if it is not the default).

[claudiahub]

After debugging on this, it seems the API for the endpoint /tasks/executions/1?schemaTarget=boot2 does not have anymore the lastExecution property attribute which is necessary on our side in order to select the proper last selected boot version after the first has launched in the task.

[corneil]

I propose we are always explicit about the version we send from UI when launching stream or task apps on a subsequent launch.

The list should display "Default version (x.y.z)" for the default version and then include remaining versions. Thus there are no options to choose that will not send a version to the backend. The logic for selecting a specific version will be to choose the Default version from application registration for first time launch and then the previously used version for relaunch.

Example: First launch when default in registration is 2.0.2

• Default version (2.0.2) (selected)
• Version (2.0.2)
• Version (3.0.0)

If the user actually chooses 3.0.0 the relaunch will show:

• Default version (2.0.2)
• Version (3.0.0) (selected)

The end result is that the version launched is the version the user intended and even changing the default between the time when the start the process and make the choice will ensure the version launched is the version they saw as Default.

We will not see the following on launches other than the first launch:

• Default version (2.0.2) (selected)
• Version (2.0.2)
• Version (3.0.0)

(Modified based on discussions below)

[jvalkeal]

"Default version" makes sense when initial first deploy happens. We probably can't remove this behaviour. With further stream "upgrades" this "default version" kind loses its meaning as it's just telling ui not to send any version info with a payload.

It's then even more confusing when you switch default version and select that when updating stream. If you update some other properties skipper doesn't error(as manifest do change) but it doesn't actually switch to a new version.

[corneil]

I agree that allowing Default version on initial launch is fine. This means that no version will be sent. After that the Default version should send the actual version to remove any ambiguity.