On 8 sept. 2010, at 18:23, Steve Ebersole wrote:
On Wed, 2010-09-08 at 18:05 +0200, Emmanuel Bernard wrote:
> On 8 sept. 2010, at 10:35, Hardy Ferentschik wrote:
>
>> - So far I haven't renamed any package names. This has the advantage our
>> existing users don't have to change their code.
>> Does it make sense to rename the packages?
>
> That's the big question to me. Feedback welcome. I could go either way.
> Pro: existing users don't have to change them
> Con:
> - we steal Solr's package which could conflict with people using Solr + HSearch
> - if we do a Solr integration one day (floating idea), we will have to do something
in the area
The general approach I like is to deprecate[1] the existing
classes/interfaces and "gut them" into classes/interfaces in the new
package, having the originals extend the newly packaged ones.
ymmv
[1] I prefer marking the stuff as @Deprecated as well adding log
warnings, as appropriate, in their constructors to let users know. This
lets users update/migrate at their "leisure" to an extent while still
being able to try out your latest/greatest.
Yes the annoying part is that this piece of code is not in our hands, It's the Solr
APIs, so we can't deprecate them.