Closed t3rminus closed 5 years ago
t3rminus
commented
5 years ago It might be a better idea to simply bundle paperclip.jar instead of the patched jar. Paperclip was designed to re-download and reapply patches automatically as they become available.
felixklauke
commented
5 years ago While I like the idea of paperclip in general, I don't want to use it here, as the docker image should have a fixed version and shouldn't apply manual patches of an unknown state when running.
t3rminus
commented
5 years ago So no plan to keep the discrete versions updated?
PaperMC 1.14.2 is on build v96. Unless there have been changes, the docker build is still v58...
Some of the listed fixes are quite significant: https://papermc.io/downloads
felixklauke
commented
5 years ago The current latest 1.14.2 build should be based on #95 (https://papermc.io/ci/job/Paper-1.14/95/) and was built a few hours ago. As this seems to very important for you, I would offer you Daily builds. The versions themselves are still fixed but once per day there is a build that builds with the "latest" docker tag and will always use the latest successful build. Would that be suitable for you?
t3rminus
commented
5 years ago I'm fine with fixed version numbers, as long as those version numbers are kept up to date with paper builds.
For instance, I'll keep using felixklauke/paperspigot:1.14.2 for now, but would like to make sure that it gets the bugfixes from paper as they are released, so I can occasionally re-pull the image and make sure my users get those bugfixes.
(Personally, this is a problem with the way Paper is set-up, and that it's tracking multiple upstream projects and API versions, which makes things confusing...)
t3rminus
commented
5 years ago If it helps, here's my usage scenario:
I will likely update to 1.14.3/1.15/etc shortly after they become available (I will test the server with a copy of the map in a sandbox environment for a few days, to make sure there are no show-stopping issues)
I understand some servers stay on a particular version for years, but I have a rather fickle audience who immediately demand releases as soon as mojang announces them (ha), but I quite enjoy exploring new game features myself, so I'll take the occasional instability as a reasonable trade-off.
t3rminus
commented
5 years ago I do want to thank you for accepting my input as well! It's been wonderful to see some of my ideas implemented.
If you'd rather not go in this direction, I'm happy to maintain my own branch as well, so let me know!
felixklauke
commented
5 years ago Hm, I'm still unsure how to handle this. With the todays Update for 1.14.3 (From build #108 at paper) I added the "latest build". that will build the latest version of 1.14. I will setup nightly builds for this. I will update this latest to 1.15, 1.16 as soon as it comes out.
t3rminus
commented
5 years ago The tags 1.13-latest (etc) is exactly what I'm looking for.
Adding 1.14-latest would be perfect (I expect the stand-alone latest version will track 1.15 when it's released)
I'm going to consider this resolved.
felixklauke
commented
5 years ago @t3rminus I came up with a completely new solutions. The old versions were still hard coded and hard to overview. But paper offers an API (https://papermc.io/api/v1/paper/${PAPER_VERSION}/latest/download) to download and track latest versions! Therefor I removed the "-latest" for now images and replaced them with the current versions. I will still come up with a new "Bleeding Edge" solution soon.
Is your feature request related to a problem? Please describe. Right now the current image for 1.14.2 contains paper build v58, while the current build is v68
Describe the solution you'd like Ideally, TravisCI could publish updated builds as they're available (or perhaps just republish frequently/daily)
It would be too much to ask for you to do this manually, but 1.14.2 is evolving quickly and bug and performance fixes are being released often, and it would be nice to stay up-to-date.