Upgrade boot firmware to r2.0_00001.1 release

[vkraleti]

Update QCS615, QCS6490, QCS8300, QCS9100 boot firmware recipes to consume
boot binaries from the r2.0_00001.1 release. Starting with this release, the firmware
artifacts are hosted using the new SPF 2.0 layout. Update the paths accordingly.

[vkraleti]

Kept the PR in draft state as I am awaiting the release notes.

[quaresmajose]

It wold be better to remove the r in the PV and keep only numbers. Having letters easily breaks the order and can cause the version to backwards. consequently adjust the SRC_URI.

[ricardosalveti]

Yeah, I'm having a hard time understanding this versioning scheme, can't we have like 2.0.0001.1 or similar?

[lumag]

The PR doesn't describe, why are we switching versions. Is there a reason why we can't continue using current versioning scheme?

[vkraleti]

The PR doesn't describe, why are we switching versions. Is there a reason why we can't continue using current versioning scheme?

The current 1.0 SPF release line is going to be in maintenance mode post GA 1.8 release scheduled E/March. All new feature development will happen only in 2.0 SPF. I'll mention the same in commit messages.

[lumag]

The PR doesn't describe, why are we switching versions. Is there a reason why we can't continue using current versioning scheme?

The current 1.0 SPF release line is going to be in maintenance mode post GA 1.8 release scheduled E/March. All new feature development will happen only in 2.0 SPF. I'll mention the same in commit messages.

I'm sorry, but that means nothing. You have been pushing versioned releases. They have increasing versions. Now the location changes and suddently the versions drops. The machine is not going to change. The firmware for those machines is not going to change. Keep the location URL and keep increasing the versions numbers. The rest is just internall processes which need to be improved.

[lumag]

@vkraleti
From my PoV, we should have proper versioned releases:

• 1.0.0
• 1.1.0
• 1.2.0 (this is for example the branch point for 2.0)
  • 1.2.1 (this is a fixup for the firmware for 2.0)
  • 1.2.2 (another fixup for 2.x line)
• 1.3.0 (this is a next release)
• 1.4.0 (new release, which gets e.g. into the 3.x branch)
  • 1.4.1 (fixup)

Now, it all started at 0.something. Just continue that line, ending up with the point releases as a fixes for the stable branches with new releases incrementing minor revision as usual.

[ricardosalveti]

Now, it all started at 0.something. Just continue that line, ending up with the point releases as a fixes for the stable branches with new releases incrementing minor revision as usual.

The main problem is that the SPF is part of the version, and as major instead of a minor. Ideally the component should have its own version, and we could have a stable release that is then consumed by a certain SPF.

The current scheme causes a mess to manage, because mainline can be newer but the 1.x / 2.x baselines will have a higher version.

[lumag]

Now, it all started at 0.something. Just continue that line, ending up with the point releases as a fixes for the stable branches with new releases incrementing minor revision as usual.

The main problem is that the SPF is part of the version, and as major instead of a minor. Ideally the component should have its own version, and we could have a stable release that is then consumed by a certain SPF.

The current scheme causes a mess to manage, because mainline can be newer but the 1.x / 2.x baselines will have a higher version.

SPF should not be a part of the version at all. The components should have independent versioning, matching what is happening with the files rather than "for which project they are currently released". Release 1.3.1 should be exactly the same fix of 1.3, if it is released for 1.x, 2.x or future 3.x.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. To prevent automatic closure in 5 days, remove the stale label or add a comment. You can reopen a closed pull request at any time.