Home » railML newsgroups » railml.misc » [railML3] Handling changes between minor versions
[railML3] Handling changes between minor versions [message #2460] Tue, 16 June 2020 10:20 Go to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 27
Registered: March 2008
Junior Member
Dear community!

As announced in this month's news article on railML.org the coordinators have been discussing compatibility between minor versions of railML 3.x. On the one hand, full compatibility results in very little flexibility to correct mistakes or improve concepts that have already been modelled in railML. On the other hand, full flexibility to make changes means we cannot guarantee compatibility between minor versions. In railML 2.x the policy has been and will continue to be that we allow new elements and attributes, but keep downward compatibility by deprecating unwanted elements and attributes instead of removing them.

railML 3.x is even more comprehensive than, and has been completely remodeled from, railML 2.x. We can expect the increased practical application of railML 3.x to result in proposals for changes that will further improve the standard. That leaves us with the question of how we should balance flexibility to improve versus the need for stability and compatibility. The coordinators are proposing the following three alternatives:

  1. Follow the path of railML 2.x in railML 3.x: downward compatibility will be guaranteed. Changes may lead to elements or attributes being deprecated, but not removed.
  2. Changes may lead to elements or attributes being deprecated. Elements and attributes that are deprecated in one minor version will be removed in the following minor version. Compatibility is only guaranteed between one minor version and the next.
  3. Changes may lead to elements or attributes being removed in a new minor version, without first being deprecated. No compatibility guaranteed.
Please post your feedback here before August 31st to allow us to include it in the development of railML 3.2, scheduled for beta release around the end of 2020.


Thomas Nygreen - Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Handling changes between minor versions [message #2512 is a reply to message #2460] Thu, 13 August 2020 15:41 Go to previous message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 42
Registered: March 2015
Member
Hello,

> The coordinators are proposing the > following three alternatives:> > Follow the path of railML 2.x in
railML 3.x: downward> compatibility will be guaranteed. Changes may lead
to> elements or attributes being deprecated, but not removed.> Changes
may lead to elements or attributes being> deprecated. Elements and
attributes that are deprecated in> one minor version will be removed in
the following minor> version. Compatibility is only guaranteed between
one minor> version and the next.> Changes may lead to elements or
attributes being removed in> a new minor version, without first being
deprecated. No> compatibility guaranteed.
We would prefer option 3 (give up compatibility between minor versions).
The current compatibility rule often stands in the way of further
development of the schema and, in our view, has little advantage when
implementing the interface software.
Furthermore, backward compatibility does not only apply to the removal
of attributes / elements: Adding a new attribute can also change the
semantics of other existing attributes, for example, by semantically
overwriting or negating the contents of other attributes. For this
reason, it is not always predictable anyway whether a change will break
downward compatibility or not.
However, different revisions of an (already released) version should
remain backwards compatible.

Best regards
Christian Rößiger
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
Previous Topic: [railML2] extend the elements under <organisationalUnits> with the <designator> element
Goto Forum:
  


Current Time: Sat Aug 15 06:23:13 CEST 2020