incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: JavaHL package namespace / migration / compatability
Date Tue, 17 Nov 2009 10:21:24 GMT
On Tue, Nov 17, 2009 at 5:54 PM, Branko ─îibej <brane@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message