Pushing potentially addon-breaking changes into bigger updates
Chaos02 opened this issue · 2 comments
Describe the Suggestion
I'm a "senior" modpack developer and including Create and its many addons into a modpack has been a real chore!!
Not only is the versioning system absolute garbage (you don't need a-z SUBversions!!) but also are there really frequent, updates that bundle changes that completely break all addons:
What I mean by that is something like these commits, that are just willy-nilly integrated into a minor minor version bump:
Minor version bumps are for things like bug or crash fixes...
Here's a little reference sheet on how to do proper versioning: https://semver.org/
What you've done by introducing the a-z sub-sub-sub-versioning is basically just eliminated alpha/beta version tag, aswell as make maintaining any sort of mod-bundle completely ridiculously hard.
My suggestion is:
- Hold of changes like these for major version bumps (that introduce many more features) or even Minecraft major version changes (like 1.19 to 1.20)!
- Use median version bumps for introducing new compatibility or new features like a new item or new config options
- Use minor version bumps for bug and crash fixes only!
Additionally I would like to address the GitHub repo structure - it's not easy to follow which commits are included in which versions (please use tags or similar!) and also the commit names (while probably funny) are really unhelpful at describing what has been changed.
Create has been a bigger project (with many people involved for a while) and with bigger projects there comes bigger management overhead but I feel like it's due to change those things.
I'm absolutely open for discussion and giving input on what works for modpack developers and what doesn't!
I hope, I can somewhat improve the QoL of everyone involved ~ Chaos
PS: given the 1600 open GitHub issues I don't expect quick responses but I really wish to provide some constructive critique here and hopefully see it implemented soon™️
Screenshots and Videos
No response
Additional Context
No response
Are you a Create developer? How do you know that we don't need a-z subversions?
All three commits listed were specifically made before the 0.5.1 release. They were not included in a 0.5 patch or "just willy-nilly integrated into a minor minor version bump". We did actually plan this out.
Create has no stable API. It has a few API-like classes that we try not to break between patch versions, but addons largely depend on (and mixin to) code that is not considered API at all. We cannot develop Create without changing its code, and figuring out how all addons interact with internal code before making every single change is not a reasonable request.
Additionally, Create's main goal is to provide features, not support addons. Of course, if addon developers suggest new APIs or pull request them, we will do some work to make sure that the new API is added to Create. However, we do not have time to scour every addon's source code (which is not even possible because some are closed source) and figure out what API we might need to add and then also make sure that once it is added the addon actually uses it.
There has not been a large-scale effort from addon developers, who outnumber the active Create developers, to design a stable API that can reliably prevent addons from breaking. I do not think it is reasonable to expect us to do all of this work.
Now, even if there was a stable API, you cannot expect it to never change. Between some major versions, the API would still receive breaking changes and addons that do not update will not be compatible. Such is the nature of software development.
As for the commit names, they always have a description that lists every change in detail that the commit made. I do not see a problem here.
