improved install flow

[Huskydog9988]

alternative to #142

[Protonull]

I'm confused as to what this actually changes. The installation instructions in the new docs/getitng-started.md‎ (typo btw) seem identical to those removed from README.md, so what is actually changing that would've prevented #140?

[Huskydog9988]

The change is that now the compose file actually points to the prebuilt docker image, and it explains how to update the server. Also 140 wouldn't happen because there isn't a prebuilt image for the new version, thus they wouldn't be running a development version.

[Protonull]

Does Docker have interactive installs/updates though? Or does it just assume that the most-recent prebuilt image is necessarily a newer version?

[Huskydog9988]

Because of how we have the ci setup, the latest tag is the newest stable version

[Protonull]

Hmmm, I suppose it's fine but I feel like it's inevitable that we're going to get issues in the future about unintended updates (eg: someone wanting to update from 2.2.0-1.21.11 to 2.2.1-1.21.11 but instead updating to 2.3.0-26.1)

[Huskydog9988]

I think we enforce semantic versioning realistically. But yea that can be an issue. I can add a thing on how docker tags work and how to apply it to the image if we really need that.

[Protonull]

It depends on whether we intend to add multi-version support to the server. If not then yes, please do the docker tag thing.

[Huskydog9988]

Id prefer if we did do multi version support

[Protonull]

It'd be a lot of work but it's definitely doable. I suppose the question is: what kind of multi-version support are we talking about? Do we maintain a mods for various Minecraft versions, but they're always using the latest protocol. Or do we have the server support outdated mods (ie, readding raw TCP support to the server)?

[Huskydog9988]

I'm thinking we just support mods (server side) that speak the same protocol version