eclipse-score / eclipse-score/score

Improvement: Define Release workflow

Open
#2,231 5 comments 1 reaction 1 assignee Claimed by @AlexanderLanin View on GitHub
community:infrastructure
Dominant language
Starlark
Stars
109
Forks
105
Avg merge
1d 9h
Merged PRs (30d)
21

Description

### What

Release workflow - we shall define a git workflow and decide how this shall work for S-CORE.
We need to know how to handle `branches`, integration into release X and its `stages`, and have this described so it's clear for everyone (also outside S-CORE)

### How

- Assumption: Release X is split into several stages: `alpha`, `beta`, `final` etc.
- At a defined `date` before the first stage we create a branch in `reference_integration` called `releases/X`
- From now on, each `module` will be pulled from the same branch `releases/X` ie. `baselibs` will be pulled from branch `releases/X`
- Releases to bazel registry for modules, for release X shall happen only from this branch
- Each module `main` shall increase `major` version of bazel module by 1 and compatibility level (probably)
- Once we reach a `stage` point on branch `releases/X` in `refernce_integration` we create final `stage` branch `releases/X_stage` and apply overrides with module versions etc. This would be there release point of given `stage`
```mermaid
---
title: Reference_integration workflow
---
gitGraph
commit id: "Some commit"
branch release/1_0
checkout release/1_0
commit id: "Integrate module X ver Y"
commit id: "Integrate module Y ver Z"
commit id: "Some other changes"
branch release/1_0_alpha
checkout release/1_0_alpha
commit id: "Apply version_overides from bazel registry " tag: "1.0-alpha"
checkout release/1_0
commit id: " "
commit id: " "
commit id: "Some other changes..."
commit id: "Again other changes..."
branch release/1_0_beta
checkout release/1_0_beta
commit id: "Apply next version_overides from bazel registry " tag: "1.0-beta"
checkout main
commit id: " "
commit id: " "
commit id: "Further Ci/CD changes from 2.0 content"
```

```mermaid
---
title: module X workflow
---
gitGraph
commit id: "Some commit"
branch release/1_0
checkout release/1_0
commit id: "Some specific changes"
checkout main
commit id: "Bump module version +1"
commit id: " "
commit id: "Some changes for main and X release"

checkout release/1_0
cherry-pick id: "Some changes for main and X release"

```
The above `Release workflow` will let us do continuous development on `main` branch, we will not need to fight with mixed content between releases. I would recommend to decide on this and execute it for `0.5-beta` and `0.5` so we have clear path for `1.0`.

### Estimates for realization

WIP

### Category

- [ ] Affects Detailed Design

### Requirements / Architecture

- [x] Requirements / Architecture are not affected by this change?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.