---
title: "Start, Release and Rollout Dates"
canonical: "https://help.releasemanagement.app/space/RMC/3181641729/Start%2C%20Release%20and%20Rollout%20Dates"
format: markdown
---
> Macro (include)

# Topics

> Macro (toc)

# Introduction

**In Release Management, everything revolves around three key dates: Start Date, Release Date, and Rollout Date.**  
While you can define [custom date or datetime properties](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/2464579589) and [additional milestones](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/1197867009)—both planned and achieved—these are typically used to capture events that occur between the Start, Release, and Rollout dates.

# How Start and Release are defined?

Start and Release dates are defined based on the release/entry type, namely:

**Versions (Fix Versions)**

It’s taken from Start and Release dates of the versions (Fix Version). Any update to these fields in Release Management will cause change in Jira versions and vice versa (manually, via automation or API) because we basically work with the same Jira entities.

**Cross-Project Versions**

These are Release Management unique entities. Once created and defined Start and Release dates will be updated in all corresponding fix versions in all corresponding projects. Any change to these dates in Release Management or Jira (manually, via automation or API) will trigger automatic re-sync of all the dates cross-project.

**Sprints**

Start/Release dates for “Sprint-based Versions“ are taken from Start/End dates of the sprint. Any change of these dates in Release Management or Jira (manually, via automation or API) will trigger either amend of sprint dates in Jira or amend of “Sprint-based Version“ in Release Management.

**Epics Not-in-Sync**

Start/Release dates for “Epic-based Versions“ are created and updated in Release Management and does not sync with any specific fields in Epic issue type, unless [https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/92078312/Configure+Release+Board+Settings#Epics-Synchronization](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/92078312/Configure+Release+Board+Settings#Epics-Synchronization) is used.

**Epics In-Sync**

In case [https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/92078312/Configure+Release+Board+Settings#Epics-Synchronization](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/92078312/Configure+Release+Board+Settings#Epics-Synchronization) is used Start/Release dates for “Epic-based Versions“ are taken from configured standard/custom fields (including other 3rd party Apps) and synched constantly.

**JQL-based Version**

These are Release Management unique entities. Once created and defined Start and Release dates for JQL based versions has no impact on any of the issues included onto the scope.

**Packages**

These are Release Management unique entities. Start and Release dates of the packages usually has no impact to any encompassing versions, unless  [https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/193953846/Managing+Packages+on+Release+Board#Synchronizing-versions-in-the-package](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/193953846/Managing+Packages+on+Release+Board#Synchronizing-versions-in-the-package) is turned on.

# What Rollout Date stands for?

For majority multi-tenant solutions (aka one-size-fits-all) Release Date is good enough to track End Date or Production Delivery Dates.

In case of single-tenant solutions or multi-tenant with blue/green deployments, other graceful rollout techniques and/or multiple geo-distributed production environments **Release date is just the beginning of Rollout phase** with possible [intermediate milestones](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/1197867009) **and Rollout End Date as final destination**.

> ✅ Release Management supports Rollout End Date as yet another system date field and allows to adjust part of Application functionality by migrating conceptually from a notion of Release Date as final destination to Rollout End Date as ultimate goal. 
> ✅ 
> ✅ In particular:
> ✅ 
> ✅ - If defined Roadmap will outline release bars up till Rollout End Date with Release Date as key milestone on the way.
> ✅ - Same goes to Calendar if “continues events“ configuration is used.
> ✅ - Otherwise, Calendar will show Rollout End Date as additional Milestones
> ✅ 
> ✅ There’s also an additional Rollout End Date filter alongside Release Date filter available.

> Macro (include)