IS_DEVELOPMENT_BUILD to false
This is more streamlined than the previous approach, and works better
for a world where 1 person isn't doing all the work.
Now, the flow is simpler:
- Do changes (e.g. protocol update), changelog & set IS_DEVELOPMENT_BUILD to false all in a single PR, which can be squash-merged if desired
- Once the PR is merged, a draft release will be prepared
- RestrictedActions will automatically set IS_DEVELOPMENT_BUILD back to
true and bump the version
- Tag will be created when the release is published
Previously, multiple PRs might be needed, and the PR containing the
release changelog couldn't be squash-merged. Manual intervention was
also required to create a tag and prepare a release.
This PR also includes new CI checks to check for basic errors like
forgotten changelog files to ensure changelog links work correctly.
Note: Only PRs from PMMP Team members with **write** access to the
repository can trigger release generation. Random people cannot trigger
release generation by sending PRs.
Because ext-phar sucks, tmp gets spammed by cache files for every thread when loading files from the phar on the fly.
Instead, we convert the `.phar` into a decompressed `.tar` in the tmp directory and require files from inside it. Surprisingly, this works because `ext-phar` supports `tar` and `zip` natively. No stream wrapper is required, as the `PocketMine.php` bootstrap loads files relative to its location, so the cache is automatically used for everything.
To be honest I would rather get rid of phars entirely, but they are still the easiest way to have PhpStorm load PocketMine-MP API information for now, and the alternatives are more complicated and inconvenient.
### Caveats
Everywhere that previously used `new Phar(Phar::running(false))` in the core code needs to be updated to use `PharData` for this to work correctly. Plugins don't need to do anything.
### Why not just use `Phar::decompressFiles()`?
This requires setting `phar.readonly` to `0`, which is a security issue. Technically, we could have used a subprocess to do this, but it just didn't seem right.
### WTF? `phar://` can be used on `tar` files???
Yup. I was just as surprised to find out that `require` works in such contexts.
### Relevant issues
- Closes#6214
## Changes
### API changes
None.
### Behavioural changes
Server startup will be slightly slower, as the phar has to decompress and convert itself into a `.tar`. However, testing showed that this generally takes less than 200 ms, so it should be barely noticeable.
## Backwards compatibility
No BC issues.
## Tests
Locally tested and the CI will also verify
Previously, we were using codegen to support describing a fixed set of enums.
Instead, we implement an enum() function, allowing any native PHP enum to be described.
All enums used in runtime data have been migrated to native PHP 8.1 enums in minor-next to facilitate this.
This implementation:
- is faster (in extreme cases by 40x, such as with PotionType)
- requires way less code
- does not require a build step
- is way more flexible
This fixes#5877, increasing the range of stuff that plugins are now able to do.
EnumTrait enums are not supported, as it's easier and cleaner to just support native enums. Most core EnumTrait enums have been migrated to native enums by now to facilitate this.
a couple of usages of properties that no longer exist couldn't be migrated.
in addition, this revealed a couple of dead properties in the default file.
this is not an ideal solution (I'd much rather model the configs using classes and map them) but in the absence of a good and reliable library to do that, this is the next best thing.
