-
Notifications
You must be signed in to change notification settings - Fork 81
DR-001-Arch: Consistent Stack vs. Reference Integration #2560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
|
|
The created documentation from the pull request is available at: docu-html |
|
Seems related to #2346, Feature as stand-alone Delivery? |
Yes agree, added it to the list in the description above. |
PandaeDo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
opajonk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is the same, at least from the discussion in the last architecture on-site where I was also participating.
(Cross-linking another related DR: #2400)
FScholPer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What option is accepted or did I miss something?
aschemmel-tech
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see inline comment
| - Specify CI/CD implementations or quality gates. | ||
| - Define release cadences or versioning strategies. | ||
| - Provide a migration plan for existing modules. | ||
| - Specify how architectural discussions are conducted or moderated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please include something like: "This approach does not prevent the use-case of independent module (or feature) delivery. I.e. the modules/features are still independent enough to be able to be released as a SEooC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aschemmel-tech I added a paragraph to clarify that it is not the goal to constrain the modularity of the stack. Does this suffice or would you like to have the wording differently?
FScholPer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no accepted option defined
@FScholPer the decision is right after the context: https://github.com/eclipse-score/score/pull/2560/changes#diff-7605e72a4577a9aeeadf15aca38407709dc0eff885ee5684e8d46097ef932da8R44 |
Formal decision record based on discussion during last architecture community workshop: https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14871055
This intends to establish a discussion basis for further technical dr's such as:
Important
This PR will be kept open at least until 13th Feb before merging to ensure that necessary reviews can be conducted.