Skip to content

Conversation

@johnsimons
Copy link
Member

@johnsimons johnsimons commented Dec 12, 2025

Updated the UI to remove the need to show versions for ServiceControl and ServicePulse, when ServicePulse and ServiceControl are shipped together, so really a single version

Reviewer Checklist

  • Components are broken down into sensible and maintainable sub-components.
  • Styles are scoped to the component using it. If multiple components need to share CSS, then a .css file is created containing the shared CSS and imported into component scoped style sections.
  • Naming is consistent with existing code, and adequately describes the component or function being introduced
  • Only functions utilizing Vue state or lifecycle hooks are named as composables (i.e. starting with 'use');
  • No module-level state is being introduced. If so, request the PR author to move the state to the corresponding Pinia store.

>(<FAIcon class="footer-icon fake-link" :icon="faArrowTurnUp" /> <a :href="newVersions.newSCVersion.newscversionlink" target="_blank">v{{ newVersions.newSCVersion.newscversionnumber }} available</a>)</span
>
<template v-if="!isEmbedded">
<span v-if="!newVersions.newSPVersion.newspversion && environment.sp_version"> ServicePulse v{{ environment.sp_version }} </span>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If may still be worthwhile to show the ServicePulse version, just not the version check.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, this is something we need to think about it, at the moment the versions are the same

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how are they the same? Wouldn't the SP version continue to be v2.x and SC v6.x?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking more about this.
From a customer's perspective, once the 2 products become one (I feel like the Spice Girls!) I don't think it makes sense to display 2 different versions, for a customer that is irrelevant.
But I do understand that we may need a way to refer to it as part of support cases and so on.
So, given that in SC for the embedded version, we are in total control of the app.constants.js file and we have the new embedded flag, we could at the frontend, combine for example the SC version + the embedded flag to generate a version that is unique for that combo, example 1.0.0-embedded. As long as we can say that 1.0.0-embedded is SC v1 and SP v2.
Anyway, just a thought.

@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Copy link
Contributor

@PhilBastian PhilBastian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, never posted my review comments

>(<FAIcon class="footer-icon fake-link" :icon="faArrowTurnUp" /> <a :href="newVersions.newSCVersion.newscversionlink" target="_blank">v{{ newVersions.newSCVersion.newscversionnumber }} available</a>)</span
>
<template v-if="!isEmbedded">
<span v-if="!newVersions.newSPVersion.newspversion && environment.sp_version"> ServicePulse v{{ environment.sp_version }} </span>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how are they the same? Wouldn't the SP version continue to be v2.x and SC v6.x?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants