Christian Boulanger wrote:
ok, maybe I was a bit too quick to complain about the wrong thing, because I was frustrated. Sorry.
Hey, no problem. Didn't get it wrong somehow. ;-)
But even if I was wrong about the particular example, I would still maintain that keeping backward compatibility as much as it is meaningfully possible is a valuable goal.
As I said, it is our intention to help people migrating their applications to newer qooxdoo releases. Those release changes will often go along with API changes, minor or major. There will be migration support by scripts and docs as much as it is feasible. Certainly it will not be an completely automatic process. Anyway, people are not forced to upgrade if they are fine to stick with a particular qooxdoo release.
I still think this is more important than to simply freeze the API (forever?). If new features demand or any clever design decisions suggest API changes, and if it makes sense to give up backward compatibility, it should be done. We all (i.e. developers and community alike!) should help those users that either want to or have to upgrade.
I have upgraded my dojo library continually and never had to change a single line of code, even though they changed the code alot internally.
No, AFAIK, not all changes were internal. They changed (well, rather blew-up) the API. What you probably haven't noticed is that you might have become decoupled from dojo's actual progress and your application is no longer state-of-the-art? :-(
Suppose, you used a widget "FooBar" in your application, it might be still in the framework and working as you expect. But in the meantime someone may have introduced a new and better one called "FooBar2". Both versions are made available just to save people to migrate their code.
There are a couple of places where dojo keeps old code or conventions around (to my limited knowledge). At some time in the future the layers for backward compatibility are removed anyway (didn't dojo 0.3 remove stuff from 0.1). This sort of redundancy or discrepancy (at large) is nothing to aim at in qooxdoo, I think.
But anyways, sorry for the overhasty nagging.
No, that's fine with me, because I am sure that many people are interested in (if not worried about) API changes, etc.
Cheers, Andreas ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Qooxdoo-devel mailing list Qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
