Goal Allow adding new APIs and deprecating old ones without breaking mods where possible.

Two options I see right now:

• Each module is called "fabric-module-v0", "fabric-module-v1", "fabric-module-v2", etc., referring to a given different version of the API (net/fabricmc/fabric/api/module/v1, v2, ... - v0 is a special case for grandfathered "v-less" APIs). The concern here is having two concepts of "versions" - the API version and the package version.
• As above, but all API versions are contained under one module ("fabric-module", with just differing packages), and removal of old API versions is marked by a major version increment. The concern I have with this is the disconnect between the package version and the API version (say, having fabric-module 1.2.0 provide v1, v2 and v3 at the same time).

The deadline on this issue is Monday. Failing a consensus, I will most likely go for option (a).

I’ve read this three times now and I still don’t understand option two.

I am however ok with option one.

@grondag - to summarize:

• fabric-module version 1.0.0 has net/fabricmc/fabric/api/module/v1
• fabric-module version 1.1.0 has net/fabricmc/fabric/api/module/v1 and /v2
• fabric-module version 1.2.0 has net/fabricmc/fabric/api/module/v1, /v2 and /v3
• Something happens that allows us to get away with a breaking change
• fabric-module version 3.0.0 has net/fabricmc/fabric/api/module/v3 only

I don't like this approach

Ok that explains why I couldn’t understand it. My brain could not grasp that you would propose something so awful. :-)

I much prefer option A.

I think A is fine, keeping backwards compat where possible and only when really needed a new vX is added.

Now would making something deprecated in API allow it to be removed come the next breaking mc version?

Now would making something deprecated in API allow it to be removed come the next breaking mc version?

Yes, that's the whole idea.