You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2014/07/30 15:20:39 UTC
[jira] [Updated] (LUCENE-5859) Remove Version.java completely
[ https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Muir updated LUCENE-5859:
--------------------------------
Description:
This has always been a mess: analyzers are easy enough to make on your own, we don't need to "take responsibility" for the users analysis chain for 2 major releases.
The code maintenance is horrible here.
This creates a huge usability issue too, and as seen from numerous mailing list issues, users don't even understand how this versioning works anyway.
I'm sure someone will whine if i try to remove these constants, but we can at least make no-arg ctors forwarding to VERSION_CURRENT so that people who don't care about back compat (e.g. just prototyping) don't have to deal with the horribly complex versioning system.
If you want to make the argument that doing this is "trappy" (i heard this before), i think thats bogus, and ill counter by trying to remove them. Either way, I'm personally not going to add any of this kind of back compat logic myself ever again.
Updated: description of the issue updated as expected. We should remove this API completely. No one else on the planet has APIs that require a mandatory version parameter.
was:
This has always been a mess: analyzers are easy enough to make on your own, we don't need to "take responsibility" for the users analysis chain for 2 major releases.
The code maintenance is horrible here.
This creates a huge usability issue too, and as seen from numerous mailing list issues, users don't even understand how this versioning works anyway.
I'm sure someone will whine if i try to remove these constants, but we can at least make no-arg ctors forwarding to VERSION_CURRENT so that people who don't care about back compat (e.g. just prototyping) don't have to deal with the horribly complex versioning system.
If you want to make the argument that doing this is "trappy" (i heard this before), i think thats bogus, and ill counter by trying to remove them. Either way, I'm personally not going to add any of this kind of back compat logic myself ever again.
Summary: Remove Version.java completely (was: add no-Version parameter to Analyzers/QueryParser)
> Remove Version.java completely
> ------------------------------
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Fix For: 5.0
>
>
> This has always been a mess: analyzers are easy enough to make on your own, we don't need to "take responsibility" for the users analysis chain for 2 major releases.
> The code maintenance is horrible here.
> This creates a huge usability issue too, and as seen from numerous mailing list issues, users don't even understand how this versioning works anyway.
> I'm sure someone will whine if i try to remove these constants, but we can at least make no-arg ctors forwarding to VERSION_CURRENT so that people who don't care about back compat (e.g. just prototyping) don't have to deal with the horribly complex versioning system.
> If you want to make the argument that doing this is "trappy" (i heard this before), i think thats bogus, and ill counter by trying to remove them. Either way, I'm personally not going to add any of this kind of back compat logic myself ever again.
> Updated: description of the issue updated as expected. We should remove this API completely. No one else on the planet has APIs that require a mandatory version parameter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org