The idea is to allow build number filtering by channels.

When the channel is not passed or explicitly declared as stable, experimental build will be filtered.
This allows people using a kind of auto updater script to only update to stable builds.

e.g.
Let's say we have 200 stable builds before and adding an experimental feature to paper.
A experimental bug fix for the chunk border lag is added.
This bugfix modifies the chunk files but we cannot see which side effects the change has in the long term.

The whole thing is an improvement for plugins as well. A Hangar plugin update can be marked as experimental and then doesn't show up in the stable channel.

>>> https://api.papermc.io/v2/projects/paper/versions/1.19?channel=stable // default if absent

<<< {
  "project_id": "paper",
  "project_name": "Paper",
  "version": "1.19",
  "builds": [
  ]
}

Here we need to explicitly pass the experimental channel as a query argument to get experimental builds.

>>> https://api.papermc.io/v2/projects/paper/versions/1.19?channel=experimental

<<< {
  "project_id": "paper",
  "project_name": "Paper",
  "version": "1.19",
  "builds": [
    0
  ]
}

To avoid passing multiple channel values as a query argument the channel are defined like log levels.

stable
experimental includes stable builds as well.

This addition can be seen as disadvantage and also as an advantage.

• (+) The user auto update most time anyways and excluding experimental builds by default could reduce the risk of server failing
• (-) We provide an easier solution to explicitly get experimental builds automatically.

I'm happy to hear your thoughts on this topic.