Skip to content

docs: [TRG] Initial Proposal for a documentation TRG "Migration Guide" (1.09) #1187

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

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
2 changes: 1 addition & 1 deletion DEPENDENCIES
Original file line number Diff line number Diff line change
Expand Up @@ -312,7 +312,7 @@ npm/npmjs/-/fresh/0.5.2, MIT, approved, clearlydefined
npm/npmjs/-/fs-extra/10.1.0, MIT, approved, clearlydefined
npm/npmjs/-/fs-extra/9.1.0, MIT, approved, clearlydefined
npm/npmjs/-/fs-monkey/1.0.3, Unlicense AND (ISC AND MIT), approved, #2964
npm/npmjs/-/fs.realpath/1.0.0, ISC, approved, clearlydefined
npm/npmjs/-/fs.realpath/1.0.0, ISC AND MIT, approved, clearlydefined
npm/npmjs/-/fsevents/2.3.2, MIT, approved, #2967
npm/npmjs/-/function-bind/1.1.1, MIT, approved, #11063
npm/npmjs/-/gensync/1.0.0-beta.2, MIT, approved, clearlydefined
Expand Down
37 changes: 37 additions & 0 deletions docs/release/trg-1/trg-1-09.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
---
title: TRG 1.09 - Migration Guide
sidebar_position: 1
---

:::caution
Proposed release date: "mandatory after": tbd
:::

| Status | Created | Post-History |
|------------|--------------|----------------------------------------|
| Draft | 12-March-2025 | Initial contribution |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to change the date to May, 16 2025 and the status to active: we'd merge it then during the committer meeting of May, 16 2025

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.


## Why

IT operations managers and end-users of a component need a way to understand the impact of a new release on their work. This could be a required database migration, a change in an API call or system behavior.

Those changes aren't obvious just based on a changelog ([TRG 1.03](https://eclipse-tractusx.github.io/docs/release/trg-1/trg-1-3)) that usually only list all PRs within a release.

## Description

A migration guide **must** contain all relevant information for IT operation managers of a component to migrate an existing component from the previous to the new version. It must be placed in a directory named `/docs/admin'.

It **must** also contain all relevant changes for end-users, such as changed API calls, component behaviour, added/deprecated customer facing features etc.

The migration guide shall _explain_ relevant changes to operators and users and not simply list them.

## Best Practices
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really hate the fact, that TRGs are currently not very consistent in their structure.

20 TRGs use Example
5 TRGs Use Best Practice
1 TRG uses Best Practices and Example

I suggest switching to Example and also including an example and scrapping Best Practice

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ClosedSourcerer Examples and Best Practices are two different things for me. I chose not to provide an example, because this always depends on the application... We could however link to "good examples" that already do that, such as the portal or the EDC. I'd still like to keep the best practices... would you suggest to add them to the "description"?


- A migration guide should support IT operations management and guide the efforts for updating dependent tools and processes.
- There should be a dedicated migration guide per release that contains relevant changes for IT operations managers or end users : E.g. From 1.1.x -> 1.2.x, 1.2.x -> 2.0.x etc.
- A migration guide should only explain those changes that require an action by IT operations managers or end-users of a component. It should not be a duplication of the changelog.

## Examples

- [EDC migration guide](https://github.com/eclipse-tractusx/tractusx-edc/tree/main/docs/migration)
- [Portal migration guide](https://github.com/eclipse-tractusx/portal-assets/blob/v2.3.0/docs/admin/Version%20Upgrade/portal-upgrade-details.md)
Loading