Improvement: Define Release workflow

[pawelrutkaq]

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

---
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"

Loading

---
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"

Loading

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

• Requirements / Architecture are not affected by this change?

[evinoth1206]

@pawelrutkaq : Thank you for bringing this up. I’m not entirely clear on why it's necessary to increment the major version by "1" for component versions after each release. Since each component already has its own release branches, and the integration repository references these branches and their commit hashes, is there a specific reason to increase the major version by "1"? Additionally, do you happen to know the details regarding the versioning schema decision for s-core components?

[pawelrutkaq]

We are referencing hashes until we do a freez and release to BRC. The rel 1.0 S-CORE shall imho not be compatible with 0.5 since assuring that will probably be hard (imagine breaking changes in communication that can happen commit later after some release branch off from main). Or i am branching 0.5, and on main integration new component that is not part of 0.5 anymore.

[dcalavrezo-qorix]

Hi @pawelrutkaq,

Is this issue still relevant? If not, please add the trash label so it can be marked for deletion.

[opajonk]

For the module versioning I would not deviate from what SemVer tells us. I think that is the expected versioning schema used these days. The overall S-CORE version is another thing and can be closer to a "marketing version" - although using SemVer also here would make everyone's life much easier. Code freezing at a specific point in time for release is certainly a good idea, so that development on main can continue with new features.