Improving the release process

[Potherca]

Originally posted by @kirchsth in #248 (comment)
related to the breaking "master": I think the safes (maybe not simplest) solution is

updated by kirchsth: duplicated post itself removed from the description - I think following steps are a better description of (my) steps and a simpler stating point for discussion

• the master branch will be never update the with the (final) release version
• only the created release/$release_version is updated and tagged with "$release_version" and "latest"
• as soon the release is finished the master branch is updated with the next beta version

0. master is finished with beta version of the release
   0.1) (manually) Check that all open issues, related to the release milestone, are finished
   0.2) (manually) Check if anything else that needs changing. Copyright year? Any contrib files? URLS?
   0.*) (manually) ...
   0.x) (manually) Check which is the next released version of the PlantUML(/PlantUML-stdlib) version.
   (it is used as $deployed_version and required in the released README.md )

1. create branch release/$release_version (based on master)
   1.1) Update all includes with $release_version in *.puml and *.md
   1.2) Update includes of all image urls with $release_version in *.md
   1.3) Replace header of README.md with release header (based on readme_release_header.txt)

   1.m1) Manually: check updated files

   1.4) Commit changes with comment "Create release (branch) $release_version"
   1.5) push release to branch release/$release_version (manual?)
   1.6) add $release_version tag to branch release/$release_version (manual?)

2. create a new $release_version release based on the $release_version tag (is branch release/$release_version, not master) (manual?)
   2.1) protect release/$release_version branch (no changes)

3. create branch feature/$next_version beta (based on master)
   3.1) Update C4.puml with next beta $next_version beta
   3.2) Commit changes with comment "Update version with first beta of $next_version (the last released version is stored in branch release/$release_version)"
   3.3) create a MR "Update version with first beta of $next_version" into master
   3.4) merge (after merge master is updated with $next_version beta1)

4. create in PlantUML/PlantUML-stdlib a MR based on
   4.1) create in a PlantUML/PlantUML-stdlib fork a C4v250 branch
   4.2) update the C4_*.puml and INFO file
   4.3) Commit changes with comment "Update C4-PlantUML to $release_version"
   4.4) create a MR "Update C4-PlantUML to $next_version"

@Potherca: I hope the update was ok

[kirchsth]

Hi @Potherca,

I added an updated version of my helper scripts in the plantuml-stdlib/C4-PlantUML/275-improving-the-release-process branch
I did not store it in my forked repository that you can simpler edit, ... it

It's a improved version of my semi-automatic steps for a release. Maybe you can use some parts as a starting point for your improvements (I will remove the outdated version from branch feature/148)

The scripts requires that the MR 273 is accepted otherwise the scripts are not working.

BR Helmut

PS.: I cannot protect a release branch (missing rights, can you assign it to me)

[Potherca]

I hope the update was ok

Absolutely! This is one of those things that'll take a few iterations anyway. Never fear to make changes!

Maybe you can use some parts as a starting point for your improvements

I've been somewhat absent lately, as my dayjob was absorbing most of my energy. Luckily, I have 3 weeks of holiday coming up, so I should be able to catch up and get things moving again. 👍

I cannot protect a release branch (missing rights, can you assign it to me)

Apparently the maintainer role is not enough, so I bumped the plantuml-stdlib/c4-plantuml-maintainers permission to admin.

[kirchsth]

Enjoy your holidays, we don't have any pressure...

I think we do it not so bad

Thank you for the rights

BR Helmut

[kirchsth]

Hi @Potherca,

I extended the transform_files.py in 275-improving-the-release-process branch that it can calculate the the $deployed_version (next PlantUML version) and the content of the plantuml-stdlib/C4 folder too.

This means we need only the "release version" and the "next release version".

Do you have some experiences with GitHub triggers and automation that we can automate the process from

• e.g. user creates a branch "release/[releaseVersion]" like "release/v2.6.0"
• the created branch is used as trigger
• and the automated process
  • finish the release branch (based on the transform_files.py scripts, details see HowToCreateANewRelease.md)
  • creates the draft releases
  • and all other required MR (drafts)
• this could then be approved by a maintainer

If yes, I could extend the transform_files.py file that I can calculate the last missing "next release version" argument too.

Thank you and BR
Helmut

[Potherca]

Do you have some experiences with GitHub triggers and automation

Yes. That is part of my day job 😄

It is possible to use branch names as a trigger.

[kirchsth]

Perfect, you are the best counterpart 😄.

I updated the python scripts in 275-improving-the-release-process that it

• can calculated the next version out of the release version
• can create the plantuml-stdlib/C4 files.

You need basically only e.g. following environment variables and all other steps of the HowToCreateANewRelease.md should be possible without any other (dynamic) properties (Github clientid or password could be missing, ...).
The export next_version=v2.7.0 and export deployed_version=V1.2022.15 is not required, it can be calculated by the script.

export release_version=v2.6.0
export deploy_repository_folder=../plantuml-stdlib

And if your trigger script can extract the release version e.g. out of the created release/{release_version} branch then we could theoretically commit all required changes. Only the MR have-to (should?) be done manually.

Can you try it?

Thank you and BR
Helmut

[Potherca]

Can you try it?

I'll see how things go on my fork. 👍

[stale]

This issue has been automatically marked as stale because it has not had activity in the past 60 days. It will be closed in seven days if no further activity occurs. Thank you for your contributions.

[kirchsth]

Hi @Potherca,

do you have time for the automation of the calls?
If not, I would merge the "275-improving-the-release-process" branch with the current scripts into the master branch.
(enables simpler manual script execution)

BR Helmut

[Potherca]

Looks like I forgot to comment back that things worked okay.

Lets merge 275-improving-the-release-process" branch in and move things further from there. 👍