What I really would like is to hear about REAL compatibility problem and not supposed compatibility problems.
The real compatibility problem is this.
I am working in a 3.10 based image NOW.
I wont have the opportunity to move my code base and find out what the compatibility problems are until 3.11 is released in 6 months time.
In that 6 months I will have generated a considerable amount of code, that may be incompatible with 3.11 but I wont have known it. I will also have been saving my packages to squeaksource, but I will not know that these packages are not useful to 3.11 users. All the 3.11 users will load my packages and will either complain or write my code off as "it never works", and I will never find out.
So, when I finally move my working image to 3.11, all my deployed production images are still in 3.10. So now I have to maintain 2 code bases of my packages. However if I could load a couple of patches into 3.10 that make them API equivalent, I wouldnt have to. Ok to do this I have to manually reverse-engineer the whole of the 3.11 effort. In short it is too difficult to contemplate, because non of the 3.11 effort was done with the expectation that it would need to be re- engineered.
This is what happened in the case of ifNotNil: ifNotNilDo: merger.
So, here we have an opportunity, Josh, could make his futures work, loadable into 3.10. Then I can start using this new wizzy api now in my existing code base, and I wont have to wait a year to be able to give him feedback.
If Elliot or Andreas or someone, could make closures loadable into 3.10 as a separate entity, then that would be of GREAT benefit to me and to Edgar apparently. I would also like the long changes file fixes (but someone told me they are available on mantis)
So in summary, I will not be ready to tell you what the compatibility problems are until about 3 months after the release of 3.11 is finished. At which point the only person who can fix them, will be me, for myself only.
Keith