Conversation
|
@Cinnazeyy what do you think of using version ranges? I have a split options, on one side it's nice to automatically get new fixes etc. At the same time it might also pull things in we don't want. Even through it should be save for libs which uses sem ver. Plugins might be a problem trough. Biggest downside is that builds are not reproducable anymore with that, so maybe no that good for the plugins itself, but only for the libs. I think we can use https://github.com/ben-manes/gradle-versions-plugin + https://github.com/kevcodez/gradle-upgrade-interactive to make it easier for us. I'm against these automatic pr's trough. At least when it doesn't combine multiple updates in one pr. |
…cies. This was done automatically via the littlerobots/version-catalog-update-plugin.
- add Java toolchain configuration via Gradle properties - add Paper-next dependency constraints - add buildPaperNext verification task - support compiling against Java 25 and Paper 1.26
|
im fine with using a version range for paper as long as that range is limited to the current major minecraft version that we want to target. (so only updates for paper patches). im not too worried about reproducibility for that. |
build(gradle): update dependencies to flexible versions and upgrade Gradle to 9.5.1
Main dependency which needed an update was XSeries in the alpslib, that errored out otherwise.
We don't want to update to Java 25 / Minecraft 26.1.2 yet, to ensure we have no breaking changes i made a compatibility build-