[Feature Request] use semantic versioning

[justmiles]

Have you read the Important information text above

• Yes i did

Describe the feature

Hi @jammsen - this docker image along with several others have proved to be a reliable source for ready-to-go servers. However, it's difficult to keep the container itself update without versioning.

Would you consider embracing semantic versioning for this repo?

https://semver.org

Additional information

• Would you be willing to help implement this feature?

Final checks

• I understand that this is a feature request function. I also understand that if i use this to report a bug report, that my issue might be un-answered closed.

[jammsen]

Hey @justmiles
In the begining phase of this project where we had a lot of releases and code changes i considered semver very hard, but i always came back to, what is a big change, what is a small change, how to automate semver analysis, whats the syntax of the "commit-message" will others follow this and not just over-explode my work to redo other commits?

Thats why i settled on releases based on the date 2024-05-05.1, would be the first release for today, as an example. This doesnt force anything on contributors. Also the people who want to auto-update or version-pin got involved so i create the following.

Branches:

• develop (default) -> Image-Tags: develop & Sha7
• master -> Image-Tags: latest, master & Sha7

This enables pinning to a commit and also enables people who want to use Watchtower.

I know theese are 2 entire topic, but in the end for automation they inter-twine with each other to give the user/admins/players the best experience.

How would you suggest to change all of that?

[justmiles]

Using a date-based versioning system is indeed a valid approach. While it may have a few shortcomings, considering the size of the project and the number of maintainers/contributors, you may find it to be the most practical approach. If you choose to continue using the date-based versioning strategy, the only adjustment I would encourage is to tag the source commit (git tag <YYYY-MM-DD.BUILD> <COMMIT ID>) with your releases to ensure alignment between the docker images and the source code.

If you are open to reconsidering semantic versioning, let me address some of the concerns you raised.

• "What is a big change, what is a small change": Semantic versioning primarily distinguishes between breaking changes and regular updates rather than just big versus small changes. It emphasizes maintaining backward compatibility and only incrementing the major version number for breaking changes. For this project, it wouldn't be uncommon to see releases progress from 1.0.0 to 1.599.0 without necessarily reaching a "major" 2.0 release. Only significant changes that break compatibility, such as fundamental backup strategy modifications or environment variable refactors, would warrant a major version change to 2.0.

• "How to automate semver": Automating semantic versioning is as straightforward as the date-based approach. Automation scripts would typically update the minor version, while major and patch updates can be handled manually. I can't imagine a need for patch updates in this project (where you needed to retro-actively update a previously released version) and major updates should be as painful to the maintainers as they are the users they're introducing the breaking change to - so avoid major updates.

• "What's the syntax of the 'commit-message'": The commit message is agnostic of your versioning strategy. What you're doing now is sufficient.

• "This doesn't force anything on contributors": Contributors largely impact the source code, while maintainers hold the authority to merge and release changes to the broader community. That said, the versioning strategy does not place any burden on contributors.

Regarding tools like Watchtower for automatic updates: I too automate my updates - I use Renovate, which effectively solves the same problem. Minor and patch releases are automatically updated, but most users prefer to avoid automatic installations of breaking changes. When a major release is available users are notified by their automation tool and can decide whether to approve the automatic deployment or perform a manual upgrade. This delineation between regular and breaking changes isn't captured with a date-based releasing strategy - discouraging automatic updates.

Again, a date-based approach is certainly valid. I'll personally still auto-update with the date-based tags and just fix-forward should any breaking changes get introduced.

Hope this helps!

[jammsen]

@justmiles Thanks for the long and somewhat complicated text 😄
Would you be willing to talk in Discord about this? I feel like a a few questions and i dont what to explode this on text in a issue which is somewhat and somehow limited creativly.

[justmiles]

Yeah for sure 😊

[jammsen]

@justmiles feel free to join Discord and DM me - Whenever you feel like it and have time

[justmiles]

Which discord server - do you have a link?

[jammsen]

https://github.com/jammsen/docker-palworld-dedicated-server/blob/develop/README.md
First link