Home » railML newsgroups » railml.interlocking » [railML3] Request for feedback on changes of our deprecation policy
[railML3] Request for feedback on changes of our deprecation policy [message #3301] 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.

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

[Updated on: Fri, 11 October 2024 17:49] by Moderator

Report message to a moderator

Previous Topic: [railML3]: RbcBorder: IS vs IL
Goto Forum:
  


Current Time: Thu Nov 14 05:58:18 CET 2024