Do we have to adjust the workflow with every new release excluding the previous ones? What is the goal here? Trigger only on the latest release without -rc* ?

Do we have to adjust the workflow with every new release excluding the previous ones? What is the goal here? Trigger only on the latest release without -rc* ?

I discussed this a bit in the issue : #4

Basically, I see the following options:

1. At the beginning of development, the new release is configured to be prerelease: true. This would mean, that latest will always point to the latest released version, never the current working one. Those will still be visible, however.
2. We do not use prerelease and exclude unwanted versions manually in the "site.yml". This can also be done for older version, where the group does not want it to be used any longer (and thus removes the hosted documentation).

Both can be done manually or automatically, the latter would, however, require changes in either the pipeline or an Antora extension.

To sketch things out a bit more:

Using prerelease (manually)

• Set attribute prerelease either after a successful release or at the beginning of the next cycle (I would prefer the latter) to true
• Work on the release
• Do release candidates
• Add any feedback
• Prepare for release
  • Last step: Set prerelease: false in "antora.yml"
• Create the release

Using exclusion

• Work on release
• Do release candidates
• Add any feedback
• Prepare for release
  • During this phase (at any point): Add exceptions for relevant release candidates
• Create the release

Regarding automation, the prerelease could always be true and the release pipeline sets it to false with a custom commit before the build is triggered (and back to true afterwards in a cleanup job).
We trigger pushes for the release already (because we need to create tags and update certain content anyway), so it would not be something completely different.

In case of the other solution, the same pipeline could instead get a job that adds sth like <tag>-rc* to the exceptions if the release is not a release candidate before the build job.