---
# System prepended metadata

title: Studio Release Strategy Proposal

---

# Studio Release Strategy Proposal

### Introduction

Since we introduced monthly release strategy, we did a great job to our commitments. However there are serveral problems:

1. Release date is not clear. 
2. Release always slip one week or two 
   1. Make next release tight
   2. Drop the release
3. Finish developements 1/2 days before QA
   1. QA need to test everything, a lot of pressure
   2. QA completed 1 day before release 
4. A lot of hotfixes
   1. 3 for 2.8 release
5. Last minute code change, hotfix beforer release
6. Taging the release Image 1 hour before the release
7. Relase day 1 and delpoy the next day



To improve the overall release propose. We will propose  **4 Phases** in our release cycle

1. **Release Justification - RJ**
2. **Features/Fixes Complete - FC**
3. **Code Freeze - CF**
4. **General Release - GR** 

We will also propose  a new branching strategy after we all confirm with the release strategy

---

### Release Justification (RJ) 

##### When: Wednesday, Two weeks before GR week



##### Description

- Dev, QA will review each US and justify if it will be **qualified** as part of the release.
  - An one hour meeting will be held to go over all items originally defined in the release.
  - PdM needs to participate to be aware of any changes. 
- If the US is **NOT qualified** , it will be dropped and added to next release. 
  - Need to communicated effectively with customers.
    - If the US becomes a hard requirement (P0), it will be added back to release

##### Note

- Only **P0 tickets** will be added to release after RJ Phase.
- **Nothing** else shall be added to the current release, **NO EXCEPTION except P0 issues**. 
  - These new requests will be added to next release, and the US/priorties need to be revisited.
  - Example of some new requests.
    - Small bugs discovered by QAs/internal users.
    - Small enhancement requests from internal users.
    - ...



##### Definitions

###### Qualified:

- QA will be finished 100% before FC phase
- For big features (umbrella): test plan should be ready by RJ Phase

###### P0 tickets

- A P1 MIXSUPPORT ticket, or hard commitement created by external customers for some defects. The fix must be applied **ASAP** 

  Some examples

  1. adding locking mechanism for reset endpoint
  2. Quick improvement of stats generation of qws project

---

### Features/Fixes Complete

##### When: Wednesday before the GR week



##### Description

- All qualifed US should be 
  - 100% dev completed
  - 100% QA completed
  - It is acceptable to fix small bugs that may have slipped through QA that are found during this phase
- A release branch is created
  - Additional fixes should be merged to release branch
  - We update master with the fixes that are merged into the release branch during that phase



##### Note (anthing else needs to be covered?)



---

### Code Freeze

##### When: Tuesday of the GR week



##### Description

- No more code gets pushed to release branch

- release tag should be created 

- any blocking bug fixes we want to do at this point have to be **approved by a manager**
  if it happens, the release tag will be moved to the latest commit on the release branch
    


##### Definition

###### Approved:

(add definition)

---

### General Release 

##### When: Last Thursday of the Months



##### Description

- Announce the release of the new version

- Review US for next release

  

**Note**

- The release date should be final and certain, unless there are unavoidable exceptions
  - TODO: clearly define these exceptions



---

### Exception Case: P0 Request