Release 0.8.0

[anutosh491]

Description

This PR finalizes the 0.8.0 patch release of xeus-cpp.

Type of change

Please tick all options which are relevant.

• Bug fix
• New feature
• Added/removed dependencies
• Required documentation updates

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.78%. Comparing base (51c3cb2) to head (5027eee).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #393   +/-   ##
=======================================
  Coverage   81.78%   81.78%           
=======================================
  Files          20       20           
  Lines         950      950           
  Branches       87       87           
=======================================
  Hits          777      777           
  Misses        173      173           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

clang-tidy made some suggestions

[anutosh491]

Thanks for the review. Merging !

[SylvainCorlay]

Thanks for releasing.

In the future, we should follow our policy on version bumps with respect to compatibility:

• Patch: you can update the package in place, all downstream software will continue working.
• Minor: you don't need to update your code, but you need to rebuild, because we potentially broke ABI.
• Major: we broke some APIs.

Making minor releases where it could have been patch will require all downstream packages to be rebuilt.

[vgvassilev]

Thanks for releasing.

In the future, we should follow our policy on version bumps with respect to compatibility:

* **Patch:** you can update the package in place, all downstream software will continue working.

* **Minor:** you don't need to update your code, but you need to rebuild, because we potentially broke ABI.

* **Major:** we broke some APIs.

Making minor releases where it could have been patch will require all downstream packages to be rebuilt.

The way I read the semantic versioning system here:

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes
    MINOR version when you add functionality in a backward compatible manner
    PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Where we can read about the motivation about the alternative rules?

[SylvainCorlay]

Semantic versioning works well for scripting languages like Python or JavaScript, but compiled languages must also encode binary compatibility in their version numbers. The system described here communicates both ABI and API compatibility in a single version number.

Example: Xeus

The xeus recipe includes:

  run_exports:
    - ${{ pin_subpackage('xeus', upper_bound='x.x') }}

This means "if you link with xeus 5.3.1 at build time, your runtime requirement is xeus >= 5.3.1,<5.4.0". This pattern is widely adopted: over 1,500 packages on conda-forge use pin_subpackage. Maintainers often rely on tools like ABI Laboratory to assess binary compatibility and versioning policies.

Impact on Downstream Packages
For a downstream package like xeus-octave:

• Patch updates to Xeus do not require rebuilding xeus-octave.
• Minor updates to Xeus are not automatically picked up by existing builds, but a new build (with the same recipe) can incorporate the update.
• Major updates to Xeus typically require code changes and a new version of xeus-octave.

Xeus also enforces a strict SOVERSION policy, following the libtool convention.

Why Strict Minor Version Discipline Matters

Xeus is a dependency for many packages (xeus-python, xeus-cpp, xeus-octave, xeus-r, xeus-lua, xeus-sql, xeus-robot, xeus-sqlite, xeus-ocaml, xeus-qt, xwidgets, etc.). A minor version bump in Xeus would force a rebuild of all dependent packages. Without this, recent builds of these packages could end up with mismatched minor versions of Xeus, causing conflicts in the solver and preventing co-installation in the same environment.
Thus, minor version bumps should be used sparingly.

If we want xeus-cpp to be a common dependency for many packages, I think it is a good idea to follow these conventions by default.

[vgvassilev]

TL;DR: I feel uncomfortable specific package managers to force upon us release rules because of their implementation details.

Thank you for writing this information. Given the information you shared this means that xeus-cpp will almost never change any major or minor version because all of the non-abi incompatible changes are implemented in CppInterOp. That means that we have no way of signal maturity: that is, shouting out that things are progressing beyond some alpha stage.

Example: Xeus

I can certainly see some benefits for conda-forge and avoiding to recompile packages. Other package managers take different routes on this. Why implementing this one rule and not the others?

While may make a lot of sense for xeus, xeus-cpp is on the leafs of the build graphs and there is little benefits there, right?

Impact on Downstream Packages

Our development team appreciates conda-forge and the work put in it but we should not be constrained by its specific understanding of the Semantic Versioning(SemVer).

Why Strict Minor Version Discipline Matters

SemVer was designed as a communication tool -- a convention to help developers convey the nature of API changes in a predictable way. However, in many modern build and packaging ecosystems, SemVer has evolved from being a guideline into an enforced rule, often stretched beyond its original purpose. Patch and minor version numbers, which were originally meant to describe source-level changes, are reinterpreted as signals for binary stability. While this approach simplifies dependency resolution at scale, it also distorts the intent of SemVer, and places unnecessary constraints on upstream maintainers who may follow different stability or release philosophies.

Software development teams should retain the freedom to define their own versioning schemes in ways that best reflect their project’s evolution, ecosystem, and audience. A small C++ library focused on ABI stability might find traditional SemVer too coarse; a rapidly evolving research project might prefer date-based or rolling releases. Both approaches can be entirely valid if they serve their users and contributors effectively.

Forcing all projects to conform to a single interpretation of SemVer, especially one adjusted for the needs of a specific package manager, risks turning version numbers into mechanical signals rather than meaningful indicators of project intent. Package management systems should adapt to the diversity of real-world software practices, not the other way around.

Thus, minor version bumps should be used sparingly.

This is the core part of the disagreement here. The software development lifecycle is Planning->Design->Coding->Testing->Deployment->Maintenance. In this model deployment is largely a small part of the process. Conda by its choice made it a central point -- I see also testing and coding being an integral part of the package manager which makes a lot of sense from integrator's perspective. However, this enforced strategy does not help developers because it slows them down. One example is that one needs to install some specific package to be able to test the xeus infrastructure for basic sanity.

If we want xeus-cpp to be a common dependency for many packages, I think it is a good idea to follow these conventions by default.

We want it to be a common dependency, but I don't want to common dependencies decide on release process of our software. Rather, I'd be much more in favor of creating more freedom in these things.

Deployment is part of the software lifecycle but not a central piece. The software teams should be let picking up on their versioning scheme, including if they chose to follow the anecdotal "Pride versioning" ;)