> On Feb 20, 2019, at 5:42 AM, Benedikt Ritter <brit...@apache.org> wrote:
>
> Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita <
> ki...@apache.org>:
>
>> Hi all,
>> Just finished merging a pull request to TEXT-104, where the JaroWinkler
>> distance was updated. The class was actually computing a text similarity
>> score, not an edit distance. The user that contributed did a great job
>> moving the logic into a separate class, then updating the method to return
>> a distance instead.
>> Later I realized this would break both behaviour and binary compatibility.
>> So just wondering what others think. Is it time to gather a few more
>> issues in text, maybe even consider updating libraries/java/etc, drop
>> @Deprecated stuff, and prepare a 2.0? Or is it too soon, and instead revert
>> moving the code to a branch, and update TEXT-104 with a note about the
>> branch?
>>
>
> This would be a bad signal to the contributor. Do you think it's possible
> to have both solutions side by side? So we keep the old class with the name
> an interface, deprecate it and put the new solution in the same package
> with a different class name?
I like this idea. What if you added an up-versioned package, running v2 and v1
side by side? Maybe too confusing. You could add v2 to the class name. Also
maybe a bad idea.
Just some thoughts that ran through my head here.
-Rob
>
> Benedikt
>
>
>> CheersBruno
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
