> I think developers tend to put too much effort on keeping things > backward compatible and sometimes that's at the expense of > quality at the end of the day. It is a hot debate in the java > world, even inside the JDK itself.
It's essentially a lose-lose choice. Without backwards compatibility, you'll end with disgruntled programmers who hate every upgrade because it means so much work. Only MS can get away with that. With backwards compatibility, you're stuck with choices that start to get hated because the world is changing and so are the requirements. Again, only MS can get away with that ;-) The Linux people have found a very interesting tactics: They make a clear distinction whether you're "inside" or "outside" (my terminology). "Inside" means inside the kernel. You're fully exposed to massive changes in any available APIs. If that's too much work, your only option is to GPL your code so they'll keep it running as the APIs change. (You're still expected to fix bugs in your code, of course.) "Outside" means outside the kernel, i.e. userland. Userland APIs are kept stable for decades if humanly possible. Hm. Maybe that's the interesting point: Don't be backwards-compatible for everything; that way lies madness. Instead, give the application programmers the choice whether they prefer a feature-complete but possibly maintenance-intensive API or a feature-restricted but eternal one. For Jooq, the easiest way would probably be adding annotations on classes, members, and test cases - could be named @Eternal or something. Something annotated @Eternal would be there to stay, even in Jooq 42.0. Something without that annotation might get deprecated, or have slight semantic changes. Of course, it would be hard to determine what could be annotated that way. It should be the kind of commitment that programmers can bet serious money on. Just tossing around ideas :-)
