Replies: 4 comments 3 replies
-
It's a really important topic, so great that you bring it up! |
Beta Was this translation helpful? Give feedback.
-
In best case the matrix has also links to successful e2e tests from the upcoming umbrella e2e testing chart. I would also try to avoid adding patch versions. Should we expect that patch versions are always compatible, i believe. |
Beta Was this translation helpful? Give feedback.
-
I also vote for the topic @evegufy brought up. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the discussion so far! That makes sense to me. @evegufy I like the idea of referring to the TX changelog in the repository. It makes the interaction and compatibility of the tx components/repos more visible to a developer, which I think is important. I will make a suggestion in form of a pull request, there we can continue discussing the details on where/what to put in the TRGs and how it could be referenced in the repo. @Siegfriedk - could you make an example? We could throw the suggestions together and concretize them through a pull request. |
Beta Was this translation helpful? Give feedback.
-
Summary
I've been thinking about an idea that I believe could be beneficial --> the inclusion of compatibility matrixes in each repository.
Description
Currently, our release guidelines (TRGs) include the provision of crucial information about helm charts. However, I'd like to suggest a more detailed approach by introducing compatibility matrixes directly in the root of each repository. These matrixes would include information about the version of the app itself and services which it depends on and components that are compatible with the current release.
Example
Here's a sample format for the compatibility matrix from our repo:
which also can bee seen as the whole file in our repo: https://github.com/catenax-ng/tx-traceability-foss/blob/main/COMPATIBILITY_MATRIX.md
Benefit
Including this information in each repository can help streamline the release process, ensuring that users have clear insights into the compatibility requirements for each release. It promotes transparency and facilitates a smoother experience for both contributors and users.
Discussion
I'd love to hear your thoughts on this proposal. Are there any additional considerations or modifications you think would improve this idea? I would like to discuss and see if this could be an senseful enhancement to the TRGs.
Looking forward to your feedback!
Best regards,
Martin Maul
From the traceability-foss project
Beta Was this translation helpful? Give feedback.
All reactions