Resolve issue with release's 3.4.0 version compatibility, the 4.0.0 release, and forward compatibility.

Add your comments directly to the page. Include links to any relevant research, data, or feedback.

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.

Relevant data

See comment section

 

Does the accepted CPEX modify a currently used CGNS format specification?

Yes

No

Notes (optionsal)

Options considered

 

Current 3.4.0 removal:

 

Option 1: Remove 3.4.0 ASAP

Option 2: Issue a patch for 3.4.0

 

Option 1: Remove 3.4.0 ASAP

Option 2: Issue a patch for 3.4.0

Description

Removed tagged version 3.4.

(1) keep 3.4.0, and release a 3.4.0-patch1 which has the CPEX removed.

(2) introduce 4.0.0 which includes the CPEX we took out (essentially a release of 3.4.0 as 4.0.0)

Pros and cons

minimize the number of CGNS users using 3.4.0

What to do about people that are currently using 3.4.0, and have files already in the format. Do we force them to use develop?

 

a patch signals that there is an issue with 3.4.0

conforms to current forward compatibility as stated in the documentation and conforms to the stated version scheme.

Need to add a new API to write 3.x files, this needs to be done anyway

unless 4.0 is introduced fast, this has the same disadvantage as option 1 for the users of the new functionality. If there are other planned features that may break forward compatibility, they need to be idendified asap.

 

 

Option 1

Yes

No

Option 1

Yes

No

Airbus

 

 

Ansys

 

no

BETA CAE Systems

 

no

Cenaero

 

no

Colorado State University

 

no

DLR

 

 

HDF Group

 

no

Intelligent Light

 

 

NASA Langley

 

no

Numeca

 

 

nVariate, Inc.

 

 

ONERA

 

no

Pointwise, Inc.

 

 

Pratt & Whitney

yes

 

SAFRAN

 

 

Sandia National Laboratories

 

no

Tecplot, Inc.

 

 

TTC Technologies

 

 

TU Delft

 

 

University of Colorado

 

 

University of Kansas

 

 

 

Option 2

Yes

No

Option 2

Yes

No

Airbus

aye

 

ANSYS

yes

 

BETA CAE Systems

yes

 

Cenaero

yes

 

Colorado State University

yes

 

DLR

yes

 

HDF Group

yes

 

Intelligent Light

 

 

NASA Langley

yes

 

Numeca

 

 

nVariate, Inc.

 

 

ONERA

yes

 

Pointwise, Inc.

 

 

Pratt & Whitney

yes

 

SAFRAN

 

 

Sandia National Laboratories

yes

 

Tecplot, Inc.

 

 

TTC Technologies

 

 

TU Delft

 

 

University of Colorado

yes

 

University of Kansas

yes

 

 

Outcome/Action items

It was decided to go with Option 2, remaining tasks to resolve the issue:

Jan 31, 2020@Scot Breitenfeld or @Mickael PHILIT will release a patched version, v.3.4.0-patch0, with CPEX0043 removed. Commits after CPEX0043 commit can remain if they do not depend on CPEX0043.
Jan 31, 2020@Scot Breitenfeld or @Mickael PHILIT will release v4.0.0, which was essentially the 3.4.0 release.
v 4.0.1 can be released shortly thereafter with new fixes committed after the 3.4.0 release.