Edit released_at date on Release Page

Problem to solve

Changing a Release's release date is only possible through the Releases API.

Proposal

Add a new field to the "Edit Release" page that allows a user to change the release date (released_at attribute).

User story

As a Release Manager, I want to add a release date to my release item using the application's UI, so that I can manage when the release will be/was ready.

🖼 SEE UX PROTOTYPES IN THE DESIGN TAB 🖼

Acceptance criteria

• On the Release form, user sees a new section called Release date. This section should display a helper text and link to the documentation, as well as an input date.
  • The field should be pre-populated with data, if applicable while editing a release entry.
• The data added to the field should populate the released_at attribute for the release api.
• A date can be set in the past, present, or future.
• The field is not mandatory, and defaults to the current date.
• User should be able to enter a date to the release manually, by typing into the field.
• Clicking calendar icon present in the input date field triggers a dropdown with a datepicker. Guidelines from Pajamas should apply.
  • Selecting a date from the calendar should populate the input date field.
• If the date selected is in the future, the release item will be labeled an Upcoming Release.
  • Once a future date is inputted/selected, a helper text should be displayed under the input field indicating an Upcoming release will be created.
• Clicking the button to Save changes will update the released at or released in information on the Release item page and overview.

Further details

This feature should also be available when creating a new Release through the UI.

Documentation

Yes, we will need to update the documentation. This page will need to be updated with new screenshots and instructions.

UX DoD

Click this to collapse/fold the UX DoD 🔽

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

*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.*