Change branch name for website publication CI to "main"

[bact]

Use "main" for branch name for the website publication at https://spdx.github.io/spdx-spec/.

According to Tech Team Meeting 2024-11-05:

Main branch is for keeping released versions

Done by updating REF_SPEC variable in .github/workflows/publish_v3.yml (Line 25).

Notes

• This work is one part for Changes needed for new branch structure #1092
• "main" branch is not exist yet.
  • This PR will not be merged until the branches got renamed.
• VERSION is the version to be published when running this workflow.
• VERSION_DEFAULT is the default version for redirection if no version is specified in the URL.

Publishing "support" branch

• From Tech Team Meeting 2024-11-05:

  For example, we may be already at 3.2, but we wan to make some changes in 3.0.1.
  We can have "support" branches (pink line) for that.

  • "support" branches can live longer (they live until the associated release is deprecated).

• For each "support/x.y." branch (a branch that will have its version published on the website as well under https://spdx.github.io/spdx-spec/vx.y.z/):
  • Need to modify REF_SPEC, REF_MODEL, VERSION and VERSION_ALIASES variables in publish_v3.yml of that branch.
  • VERSION_ALIASES in the "support" branch should not contain "latest"; it is only reserved for "main" branch
  • VERSION_DEFAULT should be kept the same across all branches.
    • All non-"main" branches are now prevented from setting the default version (see from Line 180).
    • We may later like to move this VERSION_DEFAULT from the workflow file to a separated text file instead and read the value from that, so we can have a single source of truth.

spec-parser version

• This workflow uses the spec-parser directly from its "main" branch (see REF_SPEC), with an assumption that the "main" spec-parser will work with any version of spdx-3-model and with a directory structure in this workflow (in spdx-spec).
• To be able, in the future, to specify a version of spec-parser, to be use with a particular branch of spdx-3-model and of spdx-spec, if needed (in case that there are incompatible changes), we may need to have a release branch/tag in spec-parser as well.
  • Or alternatively, via the versioning of a Python package, as proposed in Add Python packaging infrastructure. spec-parser#89 and Convert to build as a module using hatchling spec-parser#104 and

[bact]

Also note that with current branch structure, the workflow will not trigger the check in this PR, as the "on: push: branches:" in GitHub Actions is, with changes in this PR, set to "main" and we are not on the "main" yet. We are still on "development/v3.0.1", so there will be no check yet.

Has to rerun the check once the branch renaming is done. At that time, it should trigger.

[goneall]

From the branch proposal, we won't rename the develop/v3.0.1 to main until we tag it for release.

I'll create a PR to document the branch strategy more fully and get some reviews before proceeding.

[goneall]

From the branch proposal, we won't rename the develop/v3.0.1 to main until we tag it for release.

@bact 2 questions for you:

• do we need to wait until we release 3.0.1 and merge into main before merging in this PR (since it declares the default as 3.0.1)?
• are you ready for me to do the branch renaming?