My intention was to motivate you to help fill out that doc to cover the issues you're concerned about.
Are you up for helping develop the backwards compatibility concept?
Yes - but it's taking me a while to come up with my own mental topology of options. We are working on some internal stuff at the moment and I'll try to generalise that and send a PR in the next few days.
I agree with you 100%. Five more emails of awesome points in, and I'll still probably agree with you :)
Nah! Actually it is going to other way! I started off pretty much opposed to the big bang rename, but now I'm tending to think we will never be able to avoid the consequences so ripping the bandaid off may well be best. It is a pity we will lose resources/time to innovate, but on the other hand a clean slate name space doesn't make great new APIs pop into existence either, nor exempt us from an obligation to deal with backwards/binary compatibility. As Bill says in his reply, changing the name space doesn't really change how we support version-to-version and if we really wish to break compatibility for some new ideas, there is plenty (infinite) of space under the jakarta.* top level for new APIs and we can apply @deprecated to "legacy" ones if we choose to (hmmm perhaps "classic" might be better than "legacy":)
A doc of options with pros/cons is great. Doesn't have to be complete, just needs to be enough to get the ball rolling.
Yep - I think defining transition strategies and technologies is key - for big bang and incremental. I'll try to roll the ball a little in the next few days and I promise you it wont be complete.
cheers
