Contribute documentation update for defined git flow

[samuelbernardolip]

We do all code and doc changes in release/x.y.z, then

• what will be the criteria to create or merge into stable/x.y.z?
• what should be fulfilled to create a tag from the stable branch?

To first question, I think to pass into stable release/x.y.z should be running with defined pipeline demos and have docs updated. In reelase/x.y.z we only need to test with our customized pipeline.

Then for tag, we need to have better testing because we have debug prints in tag 2.0.0. As a good criterion, we must have more user feedback from stage to create a tag, so I propose to only create tag after users testing are enough.

We should publish stable/x.y.z if we haven't the time to have the feedback from users to create the tag. Then we create the tag later.

The code inside the branch jenkins/* are all files with the pipeline code.

For each development branch there will be an associated jenkins branch: jenkins/Rx.y.z for release jenkins/Sx.y.z for stable jenkins/x.y.z for tag

We can think in deliver review tasks around this between all collaborators.

We also need to review current code in published branches and do the cleanup.

[samuelbernardolip]

Already implemented, using github workflows and integrated with Jenkins jobs merging gh_workflows branch.