Niclas Hedhman wrote: > On Tue, Nov 17, 2009 at 5:11 PM, Branko Čibej <br...@xbc.nu> wrote: > > >> I don't quite understand the point of this. Here we are with a Java >> wrapper library for the Subversion APIs. The versioning rules that apply >> to it are the same as for the rest of Subversion -- in other words, we >> *must* keep the same package names in the JavaHL public API. >> > > "Must" is a strong word, and a compatible path forward is suggested. >
"Must" is just a result of what our API versioning policy promises to our users. Any number of compatibility layers won't change that. >> Is there a >> specific reason for doing a bunch of extra work that does not add any >> value to JavaHL but only adds a layer of indirection for /all/ users of >> the library? >> > > Java coding standard(s) makes very strong assertions that package > names should be 'owned' domain names, to ensure avoidance of name > collisions. Apache has maintained such for practically all projects, > incl all incoming projects, and I am somewhat confident that some of > these projects have more dependent developers than Subversion. > I'm sure they do. 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? 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. (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.) > The indirection overhead would be "optional". Do a > "s/org.tigris/org.apache/g" replace and you are good to go without the > overhead. > 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 -- Brane --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
