Skip to content
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

dcm4che migration #486

Open
Tracked by #207
Enet4 opened this issue Jul 16, 2021 · 2 comments
Open
Tracked by #207

dcm4che migration #486

Enet4 opened this issue Jul 16, 2021 · 2 comments

Comments

@Enet4
Copy link
Collaborator

Enet4 commented Jul 16, 2021

Dicoogle currently still uses dcm4che-2.x, which is deprecated. More than once plugin developers have opted in to embedding more recent versions of dcm4che for other tasks at the price of not being fully compatible with other core constructs. Sometimes they even wanted to use newer versions, but had trouble integrating them with Dicoogle, so they ended up making workarounds.

Let this issue be used to track future updates to dcm4che and decide when and how to push these changes. We also need to make an assessment of how much of dcm4che is used, both in sdk and core. The core Dicoogle project may be able to contain multiple versions, but the API in the SDK is a critical integration point.

After some discussion, we have decided to migrate the core project and the SDK to use the latest dcm4che (v5) in Dicoogle 4. It is simple an effective, only requiring one large migration step.

@Enet4
Copy link
Collaborator Author

Enet4 commented Aug 25, 2023

In my opinion, we should take the quick and painful approach of migrating everything to use the latest dcm4che at once, because the cost of migrating all core and plugins at once would pay off early and be less expensive than diluting that effort to subsequent versions.

@bastiao
Copy link
Member

bastiao commented Aug 27, 2023

In my opinion, we should take the quick and painful approach of migrating everything to use the latest dcm4che at once, because the cost of migrating all core and plugins at once would pay off early and be less expensive than diluting that effort to subsequent versions.

Yes, we have been defining and implementing a strong methodology for validation, this will give some safer guarantees to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants