| [railML3] Request for feedback on changes of our deprecation policy [message #3312] |
Wed, 04 September 2024 09:36  |
Vasco Paul Kolmorgen
Messages: 63
Registered: November 2004
|
Member |
|
|
Dear all,
Following an issue [1] and presentation at the conference [2] railML.org
is to change a deprecation policy for railML3. Please answer if you have
anything against or anything is missing.
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.
[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
|
|
|
|
| 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
|
|
|
|
Members
Search
Help
Login
Home
