Re: [railML3] Request for feedback on changes of our deprecation policy [message #3313 is a reply to message #3312] |
Wed, 04 September 2024 12:17 |
Michael Gruschwitz
Messages: 13 Registered: May 2020
|
Junior Member |
|
|
Dear railML team,
If it is well documented, there is nothing to be said against it in our
opinion.
Thank you an best regards.
Michael Gruschwitz
Am 04.09.2024 um 09:36 schrieb Vasco Paul Kolmorgen:
> Dear all,
>
> Following an issue [1] and presentation at the conference [2] railML.org
> is to change a deprecation policy for railML3.
>
> Current state: In order to remove an element or attribute we currently
> need an intermediate minor version of railML where we deprecate this
> atttribute or element.
>
> railML's suggestion:
> • Changes from one minor version to the next will be allowed without a
> deprecation phase. This allows changes that cannot have a deprecation
> phase, such as:
> o Renaming elements, attributes or enumeration values
> o Changing the minOccurs or maxOccurs of an element
> o Changing the use of an attribute (optional or mandatory)
> o Changing between xs:sequence, xs:choice and xs:all
> • Remodelling may also be done without including both the old and new
> implementation in the new version, reducing the complexity.
> • Removals that are not replaced by something new may still have a
> deprecation phase.
>
> Please answer if you have anything against or anything is missing.
>
> Crosspost to all boards in railML forum, please follow-up and answer
> in railML.common only.
>
>
> [1] https://development.railml.org/railml/version3/-/issues/535
> [2]
> https://download.railml.org/events/conferences/railml_45th_v irtual/2024-06-06_railml-nygreen_common.pdf
>
> Sincerely,
> --
> Vasco Paul Kolmorgen - Governance Coordinator
> railML.org (Registry of Associations: VR 5750)
> Phone railML.org: +49 351 47582911
> Altplauen 19h; 01187 Dresden; Germany
|
|
|