Allow specification of release start date (`starts_at` attribute)

Problem to solve

In the process of creating a Release, users may want to be able to manually specify a release timeline within the assigned milestone or if not assigned to a milestone, a start and end date.

Currently, users are able to set the released due date released_at via API. Users should be able to set this value using the UI with #39471 (closed)

Intended users

Further details

  • Use case 1: A release manager scheduling releases may want to specify the release start date rather than a milestone. This will be delivered via #39471 (closed)
  • Use case 2: A developer may be working a release that will happen prior to a scheduled milestone or within a milestone of a related release, allowing for awareness of release dependencies.

Proposal

User story 1

As a Release Manager, I want to be able to set start to my Release, so that I can choose to work within a different time frame from the one assigned to the associated milestones.

Acceptance criteria

  • Users should be able to specify the start date of a release by using the starts_at attribute.
    • Differently from released_at, the attribute starts_at should set the start date of a release and not the timestamp from when the release item was/will be created.
  • A form field should be added to the Create release and Edit release forms.
  • A datepicker input should be displayed. frontend use the gitlab-ui datepicker component
  • By default, no start_date is pre-selected in the field.
  • Relationship with milestones:
  • The starts_at attribute watches the information about a milestone added to a release.
  • If one/multiple milestones are added to a Release, and no starts_at value is specified, the milestone start date takes precedence.
    • frontend: The value should be pre-populated in the UI.
    • User should be able to edit the values manually in the input date field.
  • If a milestone is added to a Release, and a starts_at value is specified, the starts_at value takes precedence over the milestone's start date.
Attribute Type Required Description
starts_at datetime no The date when the release will be/was started. Defaults to the current time. Expected in ISO 8601 format (2019-03-15T08:00:00Z).

As a user, I want to be able to see the start date of a Release, so that I can understand at a glance when the release will start.

  • If the starts_at is specified for a release, user should see the information in the UI.
  • A timestamp should be displayed in the release overview and detail pages.
    • Starts on MMM dd, YYYY
  • Hovering the timestamp should display a tooltip with the complete timestamp.
  • frontend the created_at timestamp needs to be updated in the UI to meet the standard MMM dd, YYYY

Further details

We know that it is a problem for customers where they may want to specify a date in between two milestones because Time boxes could be different per organization. We should support changing release start and end dates manually.

If a release start/end date is a assigned to a release with one/multiple milestones associated to it, the release start/end date will always take precedence over the milestone dates.

Permissions and Security

Permissions are inherited by project permissions.

Documentation

Yes, we will need to document this feature.

https://docs.gitlab.com/ee/user/project/releases/

Testing

If a starts_at is added to a Release and the dates are outside of a milestone timeline, an alert should be added.

What does success look like, and how can we measure that?

We should see a sustained usage of release pages as this increases the supported use cases of Release Page.

What is the type of buyer?

Community Edition

Links / references

https://docs.gitlab.com/ee/user/project/releases/

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.*
Edited by 🤖 GitLab Bot 🤖