On Tue, Nov 17, 2009 at 5:54 PM, Branko Čibej <br...@xbc.nu> wrote: > "Must" is just a result of what our API versioning policy promises to > our users. Any number of compatibility layers won't change that.
Yes, but your versioning policy for sure allows incompatible changes thru some mechanism, typically major digit increment. > But could anyone who was involved with any of these > adopted projects share their experience with changing the package names? > How did that affect their users? Did they write compatibility wrappers > with the old package names, too? Did they have an equivalent version > compatibility policy? Wicket must have been one of the major ones in a similar position. Also, Wicket didn't follow the "domain name" approach that is the norm, making a change perhaps even less "needed" compared to people seeing a jar full of "org.tigris" stuff. Martijn, do you feel like digging into your buried feelings on the subject? What I remember of Wicket incubation (as a User) was that they had less stringent versioning constraints, so that it continued to live in 1.x version space, even though incompatibilities were introduced. > I'm not steadfastly against completely changing the JavaHL API and > writing compatibility layers, but I really would like to understand the > reasons; other than Java coding standards which you can't reasonably > expect to apply, since the compatibility wrapper breaks them in the very > same way that the current API does. The "benefit" of the "wrapper breakage" is that they are immediately deprecated and can be dropped in a future release. > (And of course that owned-domain rule isn't really broken as long as we > can make sure that no-one else "steals" subversion.tigris.org.) Well, I don't know who/what tigris.org really is, so I have no comment other than if you don't pay for the registration there are very little 'assurances', since it may disappear. > I don't know what you're used to, but I'd find it very strange indeed if > I had to make massive changes to my code just because some company > bought my library vendor. Not /quite/ the same situation, but for > example, we didn't have to change one line of code in Subversion to > support new versions of BDB after Oracle bought Sleepycat (I have not done C/C++ programming since 1995, and back then libraries were few and far apart.) The underlying issue is "naming conflicts", which Sun tried to address in Java with a simple scheme, but one that only works if people co-operate. Some people choose to co-operate (I, Apache and others) and some choose to ignore it. So it boils down to Apache policy more than anything, in the same way that we *choose* to not make or even re-distribute LGPL'd code, even though we have the right to do so. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
