Pre-release checklist for 0.10

[szhorvat]

Please add checklist items as they come to mind.

• Verify that test suite passes when some optional features are disabled (GraphML reader or GLPK).
  • null_communities test fails when GLPK is disabled #2137
• Check that benchmarks build and run
• Check OSS-fuzz for potential issues
  • https://oss-fuzz.com/testcase-detail/5068971350556672, possibly an uninitialized read that came to light thanks to the recent bool type change — fixed
• Run test suite with UBSan, and manually investigate findings. UBSan does not abort on error.
  • Pointer overflow in igraph_eigen_matrix() / igraph_lapack_dgesv() #2135
  • degseq_game VL method assings NaN to integer type #2136
• Test high-level interfaces with ASan/UBSan. Use a recent Clang (not Apple's) as it gives better diagnostics and float division by zero is not reported by default.
  • Python
  • Mma
• Test with a few more compilers:
  • non-Apple Clang – tested with 14.0.6
  • old GCC 4.8 – Does not compile with old GCC such as version 4.8 #2138
  • Intel compiler (classic icc)
  • Intel compiler (LLVM-based icx) — requires -fp-mode=precise, document this? Update: we now add -fp-mode=precise automatically.
• Check cross-compiling in an environment where cross-compiled executables cannot run (so no Rosetta on macOS)
  • _umul128 support check may not work when cross-compiling #2139
  • Endianness test fails when cross-compiling to macOS arm64 #2146
• Verify that changelog is complete
• Make sure that AUTHORS and CONTRIBUTORS.md are updated.
• Notify maintainers for major Linux distros and provide essential information for the 0.9 -> 0.10 transition (e.g. 0.9 py-igraph does not work with 0.10 C core, point them to Need a brief explanation of what igraph is #2014).
• ...

See #1651 for reference.

[szhorvat]

Version 0.10 of igraph will soon be released. Below is a brief summary of what package maintainers need to be aware of before packaging this major release.

• A source tarball for 0.10-rc.2 (release candidate) is available here for testing. Feedback is welcome. We hope to have a solid final release.
• 0.10 brings many breaking changes, and is not compatible with 0.9.
• Starting with this version, igraph will start using SONAMEs consistently. For igraph 0.10, SOVERSION is set to 3 (because Debian used 2 for the previous version). This allows providing multiple versions simultaneously if your package manager supports it.
• If your package system includes python-igraph, and you chose to link python-igraph to igraph, take care not to update igraph to 0.10 without also updating python-igraph to 0.10. Version 0.10 of python-igraph is planned to be released a few days after igraph 0.10 final. If you want to update igraph to 0.10 early, there are two possible solutions:
  • python-igraph can be built with a vendored version igraph, thus decoupling the two packages.
  • if your package manager supports installing several versions of packages simultaneously, be sure to link python-igraph 0.9 to igraph 0.9
• CXSparse / SuiteSparse are no longer a dependency.
• CMake 3.18 or later is now required.
• As usual, documentation for package maintainers is available here.
• Some package managers contain an outdated description of igraph. We recommend using the short description in this comment.

---

Maintainers from major Linux distros as well as maintainers who have interacted with us in the past are CC'd here:

@jgmbenoit @limburgher @antonio-rojas @dotlambda @jannick0 @yurivict @Apteryks @epsilon-0

[ntamas]

AUTHORS updated. CONTRIBUTORS.md can be updated after we merge develop back into master because all-contributors check compares the contributor list from Github with the ones we've listed in .all-contributorsrc, but the contributor list from Github contains only those people whose changes have been merged into master.

[szhorvat]

@jgmbenoit I was wondering about the purpose of this file in Debian. It appears to list all symbols exported from the shared library. Some of these have _i_ in their name. I wanted to let you know that these should be considered internal, are not part of the public API, and may change even between bugfix releases.

Update: Actually, now that I look more carefully, there are even a few that don't have _i_ but are still not considered public, such as the vector_fortran_int ones.

[jgmbenoit]

Thanks for the hint. You are correct as concerns the purpose of the d/*.symbols files. Is _i_ a naming of yours ? If so, can you make it more explicit ? I meant replace _i_ with something as _INTERNAL_.
Whatever, I will upload a new experimental version this weekend to see if discarding them causes issues.

[szhorvat]

Yes, _i_ is a naming convention in igraph. Using _INTERNAL_ would be too cumbersome, so this is unlikely to change. The vast majority of internal functions are not exported from the shared library, but a few are useful to test directly in the test suite. This is why this are exported. If you look in the headers, you will see all of these marked as IGRAPH_PRIVATE_EXPORT instead of IGRAPH_EXPORT.

[jgmbenoit]

Otherwise, have you considered to create a LD version script ? However, it may not work if the test suite is performed against the shared library.
May be you can split your tests into two groups: internal and external.
Having a LD version script will harden the library.
(NB: For the renaming of _i_ you can try to combine find(1) with sed(1) via a script.)

[jgmbenoit]

Actually the debian/*.symbols files are generated/checked by some Debian Helper (DH) tools. This is meant to reflect a good external symbol policy for software libraries. So the best to do is to export only the external symbols and keep the private ones internal. If some private are externalized just only for tests, the best move is indeed to split the tests into public and private groups.

[szhorvat]

That's a reasonable suggestion, and it was considered when symbol exports were originally cleaned up, but it would require some major refactoring of the testing mechanism. It's not going to happen in the near future. 0.10 final will have to go ahead with the current setup.

It would make sense to revisit this idea at the time when the testing setup is revised (which is planned).

[ntamas]

0.10.0 is now out so closing the issue.

[szhorvat]

@jgmbenoit I'm not familiar with Debian packaging practices, just curious why igraph 0.10 is still in Debian Experimental and not Unstable. There's a note for Experimental stating that:

Warning: This package is from the experimental distribution. That means it is likely unstable or buggy, and it may even cause data loss.

Of course it makes sense to be careful with new major versions of any software, as new features come with new bugs. But this isn't really the case with igraph 0.10. Version 0.10.2 is more polished and less buggy than 0.9.10.

I'm wondering if anything's needed from our side before Debian can adopt 0.10, or if a long wait in Experimental is just normal practice.

[jgmbenoit]

I was just focussing on other packages. I will have a closer look by the end of the coming week-end.