Hi all,
1)
Unfortunately I think the use case is important.
If we don’t have this feature, if one application provides IIDM data to other applications
and if that first application wants to use new features of powsybl (and hence a new IIDM format), it will have to wait for all client applications to have migrated to that version of powsybl and deployed a new version.
This may have strong impacts on deployment schedules in our IT systems, and does not seem acceptable.
2)
About the proposal, I am OK with most of it, but I would propose to relax the requirements on new attributes:
if a new attribute is not required by the version 1, I think in most cases it should not throw
when serializing to that version, even if the attribute is required in version 2.
Maybe this should be decided on a case-by-case basis : for some new attributes, the network
will still make sense without them, maybe with some adaptation (like transferring it to an older attributes), while for others it will not.
Best regards,
Sylvain
De : powsybl-tsc@... [mailto:powsybl-tsc@...]
De la part de MURGEY Sebastien via Lists.Lfenergy.Org
Envoyé : mercredi 20 novembre 2019 09:11
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] IIDM Versionning - questions
I think there are organisational ways to solve this type of issues. However, I understand the use case shared.
It also largely depends on the rythm of breaking changes creation in IIDM. If every two months we have to align ourselves on our releases because of IIDM XML export breaking changes, this issue will be far more important than if it is only once a year...