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

Summarize this decision in the table below. Type /date to quickly add the due date and @mention the driver, approver, contributors, and informed to keep everyone on the same page.

Status

Decided

Impact

Driver

Scot Breitenfeld 

Approver

CGNS steering committee

Contributors

CGNS steering committee

Informed

CGNSTalk

Due date

Outcome

(1) 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.

(2) Scot Breitenfeld or Mickael PHILIT will release v4.0.0, which was essentially the 3.4.0 release.

(3) v 4.0.1 can be released shortly thereafter with new fixes committed after the 3.4.0 release.

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)

X

x

Options considered

Current 3.4.0 removal:

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

(plus) minimize the number of CGNS users using 3.4.0

(minus) 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?

(plus) a patch signals that there is an issue with 3.4.0

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

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

(minus) 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

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

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: