Launch date field in milestone

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Release versus launch

• We may want to avoid the word "release" inside GitLab the product. This could potentially get confused with our git's tag feature and GitLab's ability to annotate tags, such as https://gitlab.com/gitlab-org/gitlab-styles/tags/v2.1.0.
• For now, we'll call the field the "launch date" field.

Description

• Refer to epic for context.
• With this change, a milestone can be used both combined as a sprint and a release object in one with the additional flexibility that the due date of the scoped work is different from the release date.
• For product simplicity, apply this change to both project milestones and group milestones, even though group milestones should only be used to fully get the benefits of the release concept.
• There are three date fields now: Start date, due date, and launch date.
• The start date and due date reflect when the scoped work should be done. So this could represent development time with the due date representing a code freeze. Or the due date could represent the targeted date of completing all QA and UAT. But the launch date is purposely separate so that teams can separately decide when to release code to production. (Or equivalently for business users, when features are released to customers.) Sometimes for example, work is finished, and during a planned outage, that is when code gets released to production, say on a weekend evening. This additional field provides that flexibility.
• Design the launch date field so that by default, it inherits the due date field value, unless you specifically change it.
• For the roadmap view, it would be changed, because now the launch date is a separate vertical line apart from the milestone bar.