Creating v4-dev branch #417
Conversation
| assessment: activity.assessment.toString() || '', | ||
| level: activity.level || 0, | ||
| teamImplementation: activity.implementation || {}, | ||
| // teamsEvidence: activity.teamsEvidence || {}, |
There was a problem hiding this comment.
There was a problem hiding this comment.
Actually, this is part of the mapping.componentn.ts and we do not show any team progress or evidence on that page. That is why it was not included here.
Improved dependency graph
|
Added a new change, in the dependency graph: Forgot to add support for dark mode, I just realised. I'll do that next... |
|
@vbakke I am not sure about "author" as an attribute due to data protection laws. |
|
At some point we might include a version in the data repository to the yaml. That is not so easy, because the activities.yaml/generated.yaml is not prepared for extra field (used to be in meta.yaml, which is moved to this repo) |
The author is public in github anyway. But then again, it is not any need for that in my opinion, so that is fine to leave out author. Just to verify: Is is regarding displaying version number and realse date of the DSOMM app, lets say on an About page, @wurstbrot ?
|
EDIT: Moved my comment to a line in |
| @@ -0,0 +1,8911 @@ | |||
| --- | |||
There was a problem hiding this comment.
Versioning of DSOMM-data's activity-list
At some point we might include a version in the data repository to the yaml. That is not so easy, because the activities.yaml/generated.yaml is not prepared for extra field (used to be in meta.yaml, which is moved to this repo)
Yes, I know. I've tried to find a way, but I think I ended up with two suggestions, @wurstbrot.
A) treat meta in genetared.yaml/activities.yaml differently and extract this in the new LoaderService. (Small chance we will ever get a dimension called meta)
meta:
version: x.x.x.
released: 2025-09-28
Build and Deployment:
Build:
Building and testing of artifacts in virtual environments:
etc
B) use yaml's "multiple documents" feature. Something like:
---
meta:
version: x.x.x.
released: 2025-09-28
...
---
Build and Deployment:
Build:
Building and testing of artifacts in virtual environments:
etc
...
Both alternatives need an adjustment of in the LoaderService. But not a big change in the Angualr application
There was a problem hiding this comment.
What about a data-version.yaml next to it?
There was a problem hiding this comment.
Why not using a standard like https://docs.github.com/en/contributing/writing-for-github-docs/using-yaml-frontmatter (which is like B but different)
---
versions:
- version: "2.0.0"
date: "2024-03-15" # release date of version
status: "current"
---
Build and Deployment:
Build:
Building and testing of artifacts in virtual environments:
etc
...
For the start, we just push the current version. Later, we can add old versions also.
There was a problem hiding this comment.
Ah, there is a standard for that 😀 I didn't find it.
I'm all for following a standard. (And I preferred B) over A) anyway, so that's just perfect. 🙂)
There was a problem hiding this comment.
Just had another lokk at this standard, @wurstbrot. Looks like it is a standard for GitHub Docs, to tell which application version the current document (i.e. the yaml file) applies to.
I guess in that scenario, it makes sense to have an array of versions in a yaml file document, as the documentation can apply to a variety of versions.
Shall we go for the following?
---
meta:
version: "2.0.0"
released: 2024-03-15
publisher: "https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/"
---
Build and Deployment:
Build:
Building and testing of artifacts in virtual environments:
etc
...
There was a problem hiding this comment.
Ok, adjustment in devsecopsmaturitymodel/DevSecOps-MaturityModel-data#56
See new activities.yaml
(cherry picked from commit 6c155d1)
2 participants
Let's try again. This time, creating a pull request (/merge request) into
v4-dev. I decided to call this branchv4-devso that we can reservev4to when we are ready to release.