Releases and compatibility policy

We follow a rolling development model where the tip of the master branch is expected to be stable, tested and correct. Binary packages for the latest commit on the branch, with appropriate version information are generated automatically and can be readily installed. In general the version of the code should be preferred for producing new results, but see the compatibility policy below. The main results, such as NNPDF 4.0 [BallCarrazzaCruzMartinez+21] will be produced with a frozen tag, a conda environment and a docker image so that they can be reproduced entirely.

Tags

The code is tagged to contextualize the versioning, mark significant developments and to mark versions used to produce main results. The significant releases since the code was made public are:

Version 4.0.9

Release for 4.0 N3LO; last release fully backwards-compatible with 4.0 pipeline. 4.0 runcards will still work but external tools, and data and theory not used in the 4.0 family of fits will no longer be guaranteed to work from 4.0.10 onwards Last release compatible with the old commondata format and that accepts apfel as evolution code.

Version 4.0.8

Release for the QED and MHOU papers. Miscellaneous bugfixes and small QOL improvements. See the whole list of changes in the release description. This is the last version that uses cmake for installation.

Version 4.0.7

Intermediate release with miscelanous improvements in preparation for 4.0.8. Development release with experimental features

Version 4.0.6

The last version that uses C++ objects in n3fit and validphys, and apfel for PDF evolution.

Version 4.0.5

The last version to support legacy genetic algorithms fits based on C++.

Version 4.0.4

Incremental bugfix and enhancementent release: most importantly fixing an error in the definition of integrated luminosity (Github issue #1442), as well as adding ancillary features for the NNPDF4.0 analysis and results, and extending the documentation.

Version 4.0.3

Used to produce the NNPDF 4.0 [BallCarrazzaCruzMartinez+21] fits.

Compatibility Policy

Fit runcards, and Physics results

We attempt to maintain strict compatibility for all published results for at least one major PDF release cycle, in order to be able to reproduce the current published release (while the new one is under development) and compare new and old results. For example the code that produces NNPDF 4.0 should be able to reproduce the results for 3.1 as well. Once NNPDF 4.0 is released, new developments in the code are allowed to break compatibility with 3.1, but should maintain it with 4.0 (until after 4.1 would be released).

The baseline expectation for fits is that a given runcard for a published PDF set is able to produce an equivalent PDF. If bugs are discovered in experimental data or theory predictions, new fixed copies of the data would be made with different names, while keeping the old ones in such a way that they are selected with the original runcards. Minor differences in the result can happen as a consequence of small enhancements or differences in random number generation, although that would be avoided when practicable. If significative changes are necessary, for example as a result of discovering a bug, this will be clearly indicated by a tagged release.

Analysis runcards used for published results are expected to be able to produce the same physics, while bugfixes (that don’t affect fits) or changes in presentation can happen in between. Similarly, important enough bugfixes will be marked by a tag.

Internal interfaces

We follow a “Linux Kernel” approach to internal interfaces, which do not affect the content of runcards. This means that there is no expectation of stability at all and these interfaces can change arbitrarily at every commit without any particular notice. If you wish that code such as extra modules is maintained and kept in working order with newer updates, it is highly suggested to contribute it to the main repository, along with appropriate tests and documentation. Otherwise you are on your own.