[
https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080778#comment-14080778
]
Jack Krupansky commented on LUCENE-5859:
----------------------------------------
bq. users don't even understand how this versioning works anyway
Anybody want to take a shot at a clear description that will make sense to "the
rest of us"?
I mean, don't normal users simply want precisely one thing - back compat with
their existing index, like always, plus "auto upgrade" when that is sensible?
Should a non-expert user EVER be setting the version explicitly? Some advanced
or "expert" users want to create indexes for a specific release, but let's not
confuse them with "normal" users.
I concede that this may be an overly simplistic view, but I think we should
start with where normal users should want to be, and at least elaborate in the
language of normal users precisely what additional considerations they need to
keep in mind and decisions they will have to make and what factors they will
need to consider, with specific recommendations.
And this is just Lucene. Solr... will it stay unchanged at the API level, or is
this Lucene change going to ripple out to Solr users as well?
> 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
>
> Attachments: LUCENE-5859_dead_code.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
