# 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