...
| Page Properties | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
|
Background
We would like to raise the following issue which concerns the transition from cgnslib 3.1.3 to cgnslib3.4. The following extract comes from the CGNS website https://cgns.github.io/FAQs.html
________________________________________________________________________________________________________________
Q: What do the CGNS Version numbers mean, and does the CGNS library maintain backward/forward compatibility?
A: The CGNS versions are currently numbered as follows: "Version x.y, Revision z", or "Version x.y-z". (However, the revision number is often left off, so you will typically only see "Version x.y".) The first number represents the "major" version number. Within this number, the library maintains forward compatibility. For example, Version 2.3 of the library can read a Version 2.5 CGNS file, but Version 1.y cannot necessarily read any Version 2.y (or later) file. A new "major" version number is assigned either when forward compatibility is lost, or else when there is a significant change made to the API. The second number is the "point release" number. It increments when there are relatively minor changes to the API, or with the addition of new features. The third number (the revision number) changes with bug fixes. Major releases and point releases are announced (via the Latest News page and via the CGNSTalk Discussion Group), whereas revisions are generally not announced. Note that CGNS always maintains backward compatibility: the most recent version of the library will be able to read all older versions CGNS files.
________________________________________________________________________________________________________________
Forward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself. Older versions should be able to recognize when data has been generated from newer versions. Thus, in order to assure forward compatibility, the code must be designed focusing on future, not only past and present.
We strongly believe that forward compatibility within a major version should be guaranteed. For sure, forward compatibility cannot be maintained throughout the whole life of a software and therefore major changes that break compatibility should only be implemented in a new different major version.
In the cgnslib code, forward compatibility is always ensured by cg_open function, which prevents major version incompatibilities and returns gracefully. This well designed code provision does not hold for cgnslib v3.4, which has the same major version number, but significantly different NGON data structures. Thus, the library cannot protect the API users anymore and unexpected software behaviors might occur.
So, if one upgrades to the new cgnslib 3.4, they will create CGNS files that will crash when read by other parties who are still using the previous v3.x libraries. This will lead to problems in the community whose aim is to maintain a general, portable and extensible standard that makes it easier to share files between sites and collaborators.
We should also bring to your attention the fact that even CGNS Plot v3.1.3 crashes when trying to import a CGNS file written by cgnslib v3.4.
Our suggestion is to withdraw cgnslib 3.4 and move to cgnslib v4.0. The new library will have all the desired features that promote its wide use from the users, and will conform with CGNS specifications, of course.
We believe that the decision should be taken the soonest possible, in order to ensure that a few or no files are generated from 3.4 and the API users will face just a few or ( hopefully ) no problems at all.
...