Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pushing potentially addon-breaking changes into bigger updates #5049

Closed
Chaos02 opened this issue Jul 1, 2023 · 2 comments
Closed

Pushing potentially addon-breaking changes into bigger updates #5049

Chaos02 opened this issue Jul 1, 2023 · 2 comments
Labels
type: suggestion Issue is an idea or request for a new feature

Comments

@Chaos02
Copy link

Chaos02 commented Jul 1, 2023

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:

  1. 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)!
  2. Use median version bumps for introducing new compatibility or new features like a new item or new config options
  3. 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

@Chaos02 Chaos02 added the type: suggestion Issue is an idea or request for a new feature label Jul 1, 2023
@PepperCode1
Copy link
Member

PepperCode1 commented Jul 1, 2023

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.

Chaos02 added a commit to Chaos02/TechAttack that referenced this issue Jul 2, 2023
stoopid Create "patches" and "versioning"!! >:/
Creators-of-Create/Create#5049

also: pax doesnt support the merged fabric/forge files of serilium mods so they haven't been updated aswell...
@simibubi simibubi closed this as completed Jul 4, 2023
Chaos02 added a commit to Chaos02/TechAttack that referenced this issue Jul 8, 2023
stoopid Create "patches" and "versioning"!! >:/
Creators-of-Create/Create#5049

also: pax doesnt support the merged fabric/forge files of serilium mods so they haven't been updated aswell...
@Lgmrszd
Copy link

Lgmrszd commented Jul 24, 2023

@Chaos02 letting you know that I opened #5198 with goal of improving the situations with addons. Hopefully an API could be outlined to prevent mods breaking!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: suggestion Issue is an idea or request for a new feature
Projects
None yet
Development

No branches or pull requests

4 participants