Hm how about this:
To the branches I dont expect breaking jme changes very often, as basically the image class is the only necessary one for the interface.
As resizing is not performance critical:
Fix 3.0 as base version for now, limit support to 2 last version. (aka Stable 3.0 and Dev 3.1)
-> So 3.0 can be dropped once 3.2 is the new Dev one and 3.1 is the released stable.
-> Read JMEBaseVersion (JmeVersion.getFullName()
If 3.1 call the new method via reflection
if 3.0 or fail above call alternative code in base version
That way we have a version that can be compiled against both, uses the newer methods if available.
One base version is moved to 3.1, the workaround can be removed savely.
-> Of course properly making a few comment with the version limitations to the workaround is necessary, so it can be easily removed later.
+No branches that need to be supported
+Clearly defined wich version are officially supported
+Ability to compile against base version
-If there are many of those occurences the quality might degrade
-Not possible for performance critical code.
So If i conclude correctly
1. Ignore everything except current git version (and increase the base version to 3.1)
2. Do branches for each version
3. Use Reflection for non base version methods.
I tent for 3 mostly because I think there will rarely be any change that is in performance critical code.
2 is also ok, but I dont want to make the synchronizing work, if someone else will I'm fine with it.
What are your opinions?