Yarn: Compatibility of Constant-holding classes

[liach]

Now that we've added unpick, we have constant holding classes.

I want to talk about their binary compatibility across renames. Unlike yarn names, the constant-holding classes do not have stable intermediary names; they are more like classes in the api.

We need to determine our policy on these classes to minimize the negative effect of name changes or moves of these classes on the users.

[liach]

Hmm, should we generate intermediary for the constant classes? Just in case we rename them and binary compatibility may break.

[modmuss50]

They are binary compatible as they are compile only. They can be renamed and changed just like any yarn name without worry.

[liach]

What if people try reflection on the field values?

[modmuss50]

Nothing we can do about that, it will break in dev so seems fine to me. There are loads of things people can do to cause issues, this seems like a none issue to me.

[liach]

Sure, I guess we will just enforce compileOnly configuration for the constant jar. And I've added a warning in the package javadoc as well.

On a side note, will this NbtType from base api be deprecated and scheduled for removal once we get #2201 in?

[liach]

So we now have a general grasp on the compatibility of these constant classes. If compatibility problems arise in the future, we will address in separate issues.