Change branch name for website publication CI to "main" and "develop"

[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 (packaging of spec-parser was as proposed in Add Python packaging infrastructure. spec-parser#89 and Convert to build as a module using hatchling spec-parser#104 )

[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?

[bact]

1. Since we don't have https://spdx.github.io/spdx-spec/v3.0.0/ website at the moment, and https://spdx.github.io/spdx-spec/v3.0/ redirects to https://spdx.github.io/spdx-spec/v3.0.1/ the default is already 3.0.1.

   But in terms of keeping the promise that the main should contains only the release one, I think we should wait until we actually release 3.0.1 before merging this PR (this workflow file is not part of the chapters and of the model content, we should have a freedom to adjust it after the release - including updating dependencies in the workflow if needed in the future).

   The "on: push: branches:" trigger in this PR is currently "main", which mean once we merge it any changes in main will be immediately publish.
   The same copy of this file in "develop" branch should triggered by "on: push: branches:" event in "develop" branch.

   The top of this file in main branch should look like this:

   on:
   push:
     branches:
       - main

   The top of this file in develop branch should look like this:

   on:
   push:
     branches:
     - develop

   Which means after the renaming of branches, and merges, we still have to update these files again to customize the branch name in the file to match with the branch the file actually sits.

   • The workflow in "main" branch will publish to:
     • https://spdx.github.io/spdx-spec/<release-version>
   • The workflow in "develop" branch will publish to:
     • https://spdx.github.io/spdx-spec/<develop-version> (with -RC or -draft suffix, etc)

   The URL to be published to will be configured by VERSION variable in the workflow file. It will be used by the command mike deploy --push $VERSION.

2. I think we are ready.

   But to prevent any unwanted publication during the renaming of branches,
   I will remove (commented out) the trigger section (in another PR ). So the workflow publication will be on a pause.

   Like this:

   on:
   # push:
   #   branches:
   #     - development/v3.0.1
   # ...

   Once the renaming is done and checked, we can bring that trigger listening lines back.

   Update: The PR to pause the publication workflow is Pause the publication workflow during the branch renaming #1151.

@goneall Does it sound a plan?

[bact]

(Converted to draft to prevent merging for now. See #1151)

[goneall]

Thanks @bact - sounds like a plan.

I just renamed all the branches - so we can go ahead with the other PR's.

[bact]

There will be this workflow in "main" branch and in "develop" branch.
Each of them publish to a different URL.

For example,
this workflow in "main" can publish to https://spdx.github.io/spdx-spec/3.0.1/,
while this workflow in "develop" can publish to https://spdx.github.io/spdx-spec/3.1-dev/.

The workflow should be configured to have an URL without a version number specified be redirected to an URL published from "main" branch.

[goneall]

LGTM

[bact]

@goneall @licquia I'm reviewing this again along with the new branch strategy, and I think we may need to document the mapping between the source branch/tag and the target URL more properly, to cover all known cases, including the publication of translations in supported version (that is not the latest version).

Would you mind reviewing #1155 and then we can update this PR please? Thank you.