Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display age/release date for updates #5822

Closed
Tracked by #14138
rarkins opened this issue Mar 29, 2020 · 5 comments
Closed
Tracked by #14138

Display age/release date for updates #5822

rarkins opened this issue Mar 29, 2020 · 5 comments
Labels
core:changelogs Related to changelogs/release notes fetching priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:requirements Full requirements are not yet known, so implementation should not be started type:feature Feature (new functionality)

Comments

@rarkins
Copy link
Collaborator

rarkins commented Mar 29, 2020

What would you like Renovate to be able to do?

Give a clear indication to users about when an update was released (if we have that data)

Describe the solution you'd like

We might need to offer various approaches. Here are the possibilities I can think of:

  • Raw release timestamp (accurate, but not user-friendly)
  • Pretty timestamp (e.g. 16-Mar if it's same year, or 12-Sep-2018 if it's older than a year)
  • Relative age generated by Renovate at runtime (e.g. "2 days ago")
  • Relative age generated by a hosted service using SVG (e.g. "2 days ago" but it's dynamically updated without the need for Renovate to run)

People will have different preferences, so we could satisfy this by exposing multiple values per-update to the PR body templates, e.g.

  • timestampRaw: 20200320T140201Z
  • timestampPrettyDay: 16-Mar-2020
  • timestampPrettyDayShort: 16-Mar
  • timestampAge: 2 hours
@rarkins rarkins added type:feature Feature (new functionality) needs-requirements priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others labels Mar 29, 2020
@ViralRuparel
Copy link
Contributor

will it go to each version like below:

image

or only to the latest version to which we are upgrading?

and also will it look pretty in the PR body if we show this four formats, would't it make sense to just show one thing probably timestampPrettyDay, I think.

@rarkins
Copy link
Collaborator Author

rarkins commented Apr 9, 2020

I was anticipating this to just be shown in the table, which would mean it reflects the latest version. Also, not to show all four at once but to give people the choice of which to display (because we support templates).

@ViralRuparel
Copy link
Contributor

I was anticipating this to just be shown in the table, which would mean it reflects the latest version. Also, not to show all four at once but to give people the choice of which to display (because we support templates).

Okay, got it.

@rarkins rarkins added the status:requirements Full requirements are not yet known, so implementation should not be started label Jan 12, 2021
@rarkins
Copy link
Collaborator Author

rarkins commented Aug 8, 2021

I think for this we need:

  • sanitized timestamp from datasource
  • an SVG server which returns a relative "badge" which can be embedded

Otherwise the PR will need to be regularly updated, which generates noise.

@HonkingGoose
Copy link
Collaborator

We already have badges with the relative package age in our "Merge Confidence table":

package-age-merge-confidence

Do you want to keep this issue around and do more work, or are you happy to close it and just rely on the Merge Confidence badges?

@rarkins rarkins closed this as completed Feb 16, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core:changelogs Related to changelogs/release notes fetching priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:requirements Full requirements are not yet known, so implementation should not be started type:feature Feature (new functionality)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants