Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API expansion for filtering builds by channel #102

Open
yannicklamprecht opened this issue Jun 11, 2022 · 0 comments · May be fixed by #174
Open

API expansion for filtering builds by channel #102

yannicklamprecht opened this issue Jun 11, 2022 · 0 comments · May be fixed by #174
Labels
type: enhancement New feature or request

Comments

@yannicklamprecht
Copy link

yannicklamprecht commented Jun 11, 2022

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.

@kashike kashike added the type: enhancement New feature or request label Mar 22, 2023
@Doc94 Doc94 linked a pull request Oct 28, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants