Looking from how things work, it doesn't seem hard to add additional branch for MC 1.11 and further support — most of the problems are with some deprecated stuff in MCF and consequently there are only a little changes to be made.
In fact, most of the functionality throughout IC2 seems quite similar, and thus can be lifted to a separate package, so that it'll be a shim between older MC versions and newer ones. That way no separate branch is needed and no code fragmentation will happen.
Is just no one interested in this for some reason?
MC ≥1.11 support
-
It's substantially harder than it first seems. In 1.10 itemstacks are mutable so can be passed about and changed when needed. In 1.11 itemstacks are immutable so if a function wants to change one, it has to return a completely new one. This logic change breaks an awful lot of code that expects mutability, so all of that has to be changed before it's possible to shim anything. It's especially troublesome where functions already return something, as Java only allows a single object to be returned. Also, deprecated stuff in MCF includes all the fluid handling logic, which needs to be completely ripped out and rewritten to capabilities for 1.11, and item/block registration, which all needs to be changed to match the registry system Forge uses now. Neither are terribly hard but both are an utter pain.
Shimming between 1.10 and 1.11 is possible if you have masses of redirection of methods and reflection where that's not possible, so you end up with much messier and confused code than just having two very similar code bases. Eventually the goal is to have code that can be moved between versions, like how 1.10 code could be pushed back to 1.9, with minimal changes needed. There'll be two separate code bases, but they will be very close and so porting things between them shouldn't be hard. The barrier is really to get to that point, there's a whole lot of changes that need to happen on the 1.10 branch before a 1.11 fork would be sensible. It is happening though, #176 and #179-182 are all preparation for something like the above to happen.
-
Just to point that out. I use the IC2Exp API still and i kinda want to get informed when you guys rewrite the 1.10.2 API because its also something i need to take care of...
Thanks that i get that through the backdoor. -
It's good you are working on it
Though I would argue that copying stacks just to check the fluid type doesn't seem like the right idea, there are tank properties, and that's one of the examples where a separate method would be handy. One for tankproperties, another for old logic. Well, if separate code base isn't a problem, than some code definitely needs to be rewritten before forking, I agree (especially mutability). What I say is it doesn't seem to be rewritten in a meaningful way right now that will help that much further.
Also, immutability is not such a big problem. Well, there are places where there might be needed some architectural changes to escape too much of copy-and-change, it's just time consuming usually. (And also produces an infinity of bugs along the way). Java went a long way from mutable times, and that's where lambdas are useful. As for single return, if it is really needed to return multiple values (though I don't see right now how that is required when changing mutable to immutable), tuple is always good enough, and most changes associated with such can be easily refacrored.
As for capabilities, most stuff is already written and now requires only to be separated to diffeent classes it seems (and to implement quite simple methods get/hasCapability and initCapabilities). Yeah, painful, but will need to be done still.
Anyway, that's just my opinion here, carry on the great work