Add color background per version type in version-chooser

[patrickelectric]

Summary by Sourcery

Add dynamic background gradients to version cards based on version type, introduce a beta version checker, and adjust card spacing.

Enhancements:

• Apply a linear-gradient background on version cards using CSS variables mapped to stable, beta, and other versions
• Introduce a backgroundColor computed property to classify image tags as stable, beta, or critical for styling
• Add an isBeta utility function to the Kraken Utils module for beta version detection
• Update version card margin classes for consistent spacing

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Version cards now feature a dynamic gradient background colored by version type (stable, beta, or other) via a new computed property and utility functions, along with a minor spacing adjustment.

Class diagram for updated VersionCard component and Utils functions

classDiagram
    class VersionCard {
      +backgroundColor(): string
      asTimeAgo(value: string)
    }
    class Utils {
      +isStable(version: string): boolean
      +isBeta(version: string): boolean
    }
    VersionCard --> Utils: uses

Loading

File-Level Changes

Change	Details	Files
Add gradient background style based on version type	Introduced :style binding to apply a linear-gradient using backgroundColor Defined backgroundColor computed property to return color for stable, beta, or other tags Imported isBeta and isStable utilities for version checks	core/frontend/src/components/version-chooser/VersionCard.vue
Implement isBeta utility function	Added isBeta to detect beta versions by checking tag content	core/frontend/src/components/kraken/Utils.ts
Adjust version card margin spacing	Updated card class from my-4 to my-1 for tighter vertical spacing	core/frontend/src/components/version-chooser/VersionCard.vue

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Consider using a semantic‐versioning library (instead of regex) to more accurately classify stable/beta versions and avoid accidentally misclassifying patch or prerelease tags.
• Rather than inlining the gradient style, extract it into named CSS classes or theme variables to improve maintainability and keep the template cleaner.
• The change from my-4 to my-1 affects card spacing—please verify this aligns with the intended design and remains consistent across breakpoints.

Prompt for AI Agents

Please address the comments from this code review:
## Overall Comments
- Consider using a semantic‐versioning library (instead of regex) to more accurately classify stable/beta versions and avoid accidentally misclassifying patch or prerelease tags.
- Rather than inlining the gradient style, extract it into named CSS classes or theme variables to improve maintainability and keep the template cleaner.
- The change from `my-4` to `my-1` affects card spacing—please verify this aligns with the intended design and remains consistent across breakpoints.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[rafaellehmkuhl]

The idea is awesome and will help a lot when picking a version.

It would be nice to try sticking more to the current color palette. Probably @ArturoManzoli or Elisa can help.

[ES-Alexander]

Nice update!

Doesn't work in light mode:

It'd be nice to also add a text description of the release stabilities¹ (like was discussed in the meetings), but I suppose that could also go in a separate PR 🤷‍♂️

@rafaellehmkuhl the PR is using dynamic colours from the BlueOS theme (which are also used in the failsafe diagrams, and the user can override if they want to). Whether those colours should be changed is out of scope for this PR.

Footnotes

1. Could be something like "Stable releases are validated and tested, and recommended for most users. Beta releases contain bug-fixes and new features, but may not have been extensively tested. Development releases may be untested, and are only suggested for briefly testing specific development changes. See the documentation for more details." ↩

[ES-Alexander]

Suggested change

	:style="{ background: `linear-gradient(135deg, #1E1E1E 20%, ${backgroundColor} 100%)` }"
	:style="{ background: `linear-gradient(135deg in oklab, var(--v-outline-base) 20%, ${backgroundColor} 100%)` }"

oklab and oklch are in baseline CSS, so we may as well use perceptually linear colour spaces where we can, at least for transitions/gradients.

I'm defaulting to oklab here because it's slightly more intuitive as a transitive space, but oklch provides more vibrant (/less grey/muddy) gradients at the "cost" of occasionally introducing interim colours as it sweeps around the hue wheel, so is also worth considering 🤷‍♂️

---

Per my earlier review comment, the starting colour should account for the light/dark mode status. I'm unsure whether this is the best approach, but it does use a variable that's already used elsewhere in the software (e.g. for failsafe icon outlines), so at least avoids defining something completely new to maintain and document.

[patrickelectric]

Thanks, the outline-base did not work, I moved to transparent and the result is much better.

[patrickelectric]

@ES-Alexander check the new images in the PR

[ES-Alexander]

the outline-base did not work

Curious - I wonder why... Ahh yeah, it's the opposite side of the lightness spectrum, so the text gets hidden.

I moved to transparent and the result is much better.

Fair enough - nice! :-)

check the new images in the PR

@patrickelectric it looks good, but the "Running" indicator is seemingly hard to read in light mode, and I expect it would be even harder to read on stable versions (where the background is green). Maybe the background of the "Running" rectangle should be made less transparent, and possibly less green?

[ES-Alexander]

@dgudiel mentioned the appearance of this isn't super consistent with other parts of the interface.

The suggested alternative is to add stability chips (e.g. "stable", "beta", "dev"), like GitHub's version labels: