What are the versioning/dev rules of stdlib?

[PierU]

@hkvzjal

Let me take the get_line procedure for example: the previous naming did not respect the Style Guide and a new procedure was being introduced next to it mimicking the incorrect style: A debate in the PR was opened (guilty) regarding what to do, it was decided that the wrong style could be fixed to avoid future developments inherenting from it and keep things homogeneous.

I get that. However:

• it’s sometimes possible to fix an issue in an API without breaking anything. For instance in this case by keeping the faulty getline() while adding the new get_line(). And describing only the latter in the updated doc. That way, existing codes calling getline() continue working.
• a safe usage of the library requires to clearly know at which points an API change may occur. And it is seems that at the moment API changes can occur at any point, which is actually not safe at all for the users.

@certik

Fortran traditionally has not been changing, so if we do things right, we won’t need to increase the major version. I think we should truly aim for no changes to API. We can add new functionality with different functions, but we should never change an existing “stable” function API.

In the software of our company, if we write/integrate a library for our internal usage, the API MUST NOT change afterwards. No exception. If breaking changes are really needed, we have to duplicate the whole library and change the name (and the names of all the public entities of the library), and the old one stays “forever”. So, you really think twice(**n) before changing anything…

@certik

Since get_line is “experimental”, we can change the API. That’s what “experimental” is there for.

To make progress, let’s propose to graduate some functionality from “experimental” to “stable”.

I don’t know if this page is up-to-date, but it looks like that everything in stdlib is considered as “experimental” at the moment? Which means that API changes could occur everywhere at any time? If it’s the case, I simply can’t integrate/use it…

And on a longer term, anything “experimental” should be in a separate branch (or separate branches). That way, the corrective maintenance would be decoupled from the ongoing developments.

@wspector

With this in place, one can add all the optional arguments one wants, and in any order, without breaking existing code.

This is actually not that simple. In your description, the new API is indeed backward compatible with the old one, but the new ABI is not compatible with the old one. If the library is distributed as a binary file, this is a breaking change.