When you publish multiple versions of a package, you can navigate to the Package Registry and view Other versions. When looking at other versions, the primary list item detail is the name... again. Since each of them has the same name, we should remove the name and simplify how we are presenting this page.
We make it easier to find and verify a given package version by making the content on the page easier to read/grok.
Proposal
Update the design for the Other versions tab to present only the information that will be useful in finding and verifying a specific version of a package. For example, remove the duplicate names.
Proposed UI
Further details
Permissions and Security
There are no permissions changes required for this change.
@trizzi I created two comps for simplifying the "Other Versions" tab (see designs above).
Simple Version: Only includes the version name, when it was published, and delete. I've also included tags as this can help users understand the current standing of a version.
Simple w/ Pipeline: I've added a subtle nod to the pipeline that created it if was built via pipeline. I'm not sure if this is valuable?
Thanks, @trizzi! I've updated the issue description for a SSOT. Is there anything else we need to address design-wise for this issue or can we count the design as done?
@10io I remember when we first created the "Other Versions" tab, there was a situation with NuGet (I think) where other versions have an additional piece of metadata like an OS? Does this ring a bell to you?
Iain Camachochanged the descriptionCompare with previous version
Moving this to 14.4 to finish up the work to convert the package registry UI to use GraphQL. Since #330846 (closed) is scheduled for 14.3, this needs to move back.
Thanks for the tag @trizzi, I'm curious to learn more about the use case of other versions. Who sets these up, how are the attached to the this particular package, and why would you have them?
@katiemacoy Versions of packages are updated frequently as updates are made to the underlying code or dependencies. Changes can really be anything. For instance check out this react package on the public npm registry: https://www.npmjs.com/package/react. It has 589 versions, which get added and iterated on over time.
The person that would create them is a developer that has to make a change. The current problem is that we don't combine these in one view as in the react example above. This can make it hard to find or verify the package you want in the UI. The risk of using an old version may introduce bugs or vulnerabilities into your code.