Skip to content

Identification of historical releases in the UI

Problem to solve

User story

As a user, I want to be able to identify release items that were created with a date in the past, so I can understand that release and know what to expect regarding the evidence collection, which is not present in historical releases.

User experience goal

Users would be able to identify when a Release is created with a date in the past through a label and timestamp in the UI.

Problem overview

When a Release is created with a future released_at attribute, it is identified as an Upcoming Release (see documentation). This affects the creation of Evidence: with #38103 (closed), Evidence creation is scheduled for the released_at timestamp, rather than when the Release object was created.

There is also the concept of historical releases, when a Release is created with a date in the past. In #38103 (closed) no Evidence is created for these Releases, as it is not easily known which milestones and issues were present at this historical data.

Within the Release model, a helper method identifies historical Releases.

Intended users

UX DoD (Definition of Done)

Click to see the UX DoD (Definition of Done) tasks 🔽

Entry Criteria for Design

  • Problem has been validated
  • Has UX effort accounted for in long term cycle, we know unknowns

Criteria for UX DoD

  • UX label is added to the issue
  • User stories and acceptance criteria have been created
    • Edge cases were considered
  • Cross-team dependencies have been identified, if applicable
  • Prototype or mock for each user story have been created
    • Empty states
    • Responsiveness
  • If changes involve copy, UI text label has been added
  • Pajamas: UI Component design have been identified
    • Pajamas issue is created (new workflow)
  • Marked as Ready for engineering evaluation per user story moved into workflowplanning breakdown & needs weight

Entry Criteria for Ready for Development

  • Scope has been defined and reviewed with engineering
  • User stories have been weighed and are less than 5 MRs
  • Create new issues for follow up user stories

Criteria for Engineering DOD (in addition to defined process)

  • UX review for MRs that include user experience changes - mandatory for frontend that has impact to UI/UX
  • Update SSOT in issues:
    • Update prototypes of deliverables
    • Add link to documentation
  • Create new issues for follow up and open scope

Proposal

  • In the API, a release can be created with the released_at attribute in the past (as in, prior to the date in the user's local environment/GitLab instance).
  • If a past released_at is used, no Evidence is collected for the Release (see documentation).
  • When the released_at attribute is set in a past date, and the release is created/updated, the release item in the UI should display a badge component next to the release title.
    • The label should read: Historical release
    • A tooltip should be displayed on hover: This release was created with a date in the past. Evidence collection at the moment of the release is unavailable.
    • frontend use the Neutral color (gray) for the badge.
    • frontend verify the possibility to use the gitlab-ui Badge component
    • frontend & UX should comply with the Pajamas Badge Guidelines
  • The release timestamp in the UI should read: Created <timestamp> ago by, followed by the user avatar. Hovering the copy should display a detailed timestamp.
  • Ordering of release items in the overview page. Releases should be displayed following the most recent to older order in the Releases overview page, ordered by the released_at attribute. For example:
- v5.1 feb 2020 (Upcoming release)
- v5.0 jan 2020
- v4.0 dec 2019
- v3.0 nov 2019 (Historical release)
- v2.0 oct 2019
- ...

Documentation

What is the type of buyer?

GitLab Core +

Is this a cross-stage feature?

No

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖