Skip to content

Latest commit

 

History

History
105 lines (95 loc) · 6.06 KB

2024-11-05.md

File metadata and controls

105 lines (95 loc) · 6.06 KB

SPDX Tech Team Meeting 2024-11-05

Attendees

  • Alexios Zavras
  • Arthit Suriyawongkul
  • Bob Martin
  • Dick Brooks
  • Gary O'Neall
  • ilans
  • Jeff Licquia
  • Joshua Watt
  • Karsten Klein
  • Peter Monks
  • Sean Barnum

Agenda

  • Branch policy for spdx-spec and spdx-3-model:
    • Follow up from last week and from the mailing list
  • Using Mermaid in Markdown for diagramming
  • AbstractClass PR in spec-parser

Notes

AbstractClass PR in spec-parser

  • This PR is not get merged yet spdx/spec-parser#158
  • Joshua: shacl2code is updated to 0.0.15 (on 30 Oct 2024) in preparation for that https://pypi.org/project/shacl2code/
  • Arthit: from what Alexios mentioned in Outreach meeting 2024-11-04, PRs in spec-parser is planned to be merged around Monday or Tuesday next week (11-12 Nov)
    • Then after that, Alexios will coordinate with Arthit about spdx-spec website (updating CI)

Branch policy

  • Alexios proposed to use Mermaid to chart out the branch strategy, so we can have the same picture and at the same time can edit the diagram easily
  • The group recap a bit on translation files.
  • Sean explains Gitflow
    • Main branch is for keeping released versions
    • Development happens in "develop" branch (yellow line; long-lived).
    • Individual development activity (Features) will occur on "feature" branches (green; short-lived) off of and merged back into "develop"
    • Once the state of content on the "develop" branch is ready for release a "release" branch (purple; short-lived), which meant to be short-live and for administrative purpose will be created off of "develop" at the appropriate commit.
    • Once administrative release activity on the "release" branch is complete we can merge the "release" branch to "main" and make a tag (the tag will typically have a version number that similar to the release branch) and then also be merged back into "develop" branch
  • small well-understood "fixes" for errors or bugs on the latest release on "main" branch are done using "hotfix" (short-lived) branches off of and merged back into "main"
  • CURRENT STATUS: Currently in our "spdx-spec" repo, the "release" branches are named "development/vX.X.X" and long-lived
    • Which is different from the short-lived character descirbed earlier in Gitflow.
  • Alexios: it will be nice that both spdx-spec and spdx-3-model use the same branch strategy
  • Sean: There will be a lot of branches going in parallel, but in Gitflow the two long-lived braches will be "main" and "develop".
  • But there can be chances for some other branches to live longer. 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).
  • "hotfix" branches (red; short-lived) can be applied to "support" branches (and a tag can be made there as well - also can made a rebase back to "main"/"develop").
    • Translations can be considered as "support" branches.
    • There can be significant complexity in coordinating merging/rebasing of "support" branch changes into "develop" and other "support" branches
  • At a point of time, when you decided to end a support of arelease, you cut it and that support branch will stop.
  • Alexios agreed with the proposal and the way translation will like the "support" branch but we may need other name than "support".
  • Consensus that "support" branches will be named something like "support/3.0"
  • Alexios: As 3.0.1 and 3.0.2 will not happen in the same time - they are sequencial - so at the PATCH level (third-level in MAJOR.MINOR.PATCH version number convention) we will not go parallel.
  • Consensus that we will only have support branches at a major.minor (e.g., 3.0) level
  • Sean: Support the formality of having a branch diagram here; using Mermaid

Diagramming

Implementing the branch strategy

  • Gary: We will start with spdx-spec, because its strcture is closer to what we have just discussed.
  • Naming the "support" branch (for translation)
    • If we use "support" name as it is in Gitflow convention, people will understand its behavior and we can use the existing tooling which rely on that naming convention.
  • For older versions (1.x, 2.x), we may use the name "legacy" for branch names
  • Gary: Will we doing localization for v2.3?
  • Alexios: We already have Japanese translation for v2.3.
  • Discussion on tag/branch/commit .. to keep the history in "support" branches
  • Use "support" branch for localization and put it to "main" branch
  • Agreed to remove the "v" in branch names

Action items

  • Gary will create/rename branches in spdx-spec and spdx-3-model repos
  • In the spdx-spec repo:
    • Rename the currently under development branch "development/v3.0.1" to "develop"
    • Change the default branch to "develop"
    • For each branch under "development/*", create a branch under "support" with exactly the same commit history of that "development" branch with the name "support/X.Y", then delele the "development" branch
      • e.g. create a "support/2.3" with the same commit history as "development/v2.3", then delete the branch "development/v2.3"
      • Note this should be the same as renaming development/v2.3 to support/2.3
  • In the spdx-3-model repo:
    • Wait for the 3.0.1 release - tag the release then ...
    • Create a "develop" branch off of "main"
    • Change the default branch in GitHub to "develop"
    • Create a branch off of main "support/3.0"
  • Gary to create issues documenting the above steps
  • Alexios and Sean to review the issues
  • Once reviewed, Gary will execute the changes to the spec repo