[
https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080242#comment-14080242
]
Hoss Man commented on LUCENE-5859:
----------------------------------
bq. I removed dead code. There are plenty of lucene classes (including
analyzers etc) that don't have Version params. If we need to add one, we just
deprecate the default ctor and add it.
I want to make sure we're crystal clear about what you are suggesting, because
it seems to be the exact opposite of what you were advocating for when you
opened this issue.
You seem to be saying that moving forward, starting with 5.0, some class
"FooAnalyzer" should not have any Version param in it's constructor. if at
some point (hypothetically: after 5.2 is released, and before 5.3) and issue
like LUCENE-5482 pops up that adds improvement to the behavior of FooAnalyzer,
but would break backcompat for anyone who had already used FooAnalzyer to build
an existing index, then what should happen is:
* we should mark the {{FooAnalzyer()}} constructor as deprecated
* we should add a {{FooAnalzyer(Version matchVersion)}} constructor that adds
the improved behavior when {{5.3 <= matchVersion}} otherwise uses the previous,
non-improved, behavior
* we (presumably) update the FooAnalyzer class level javadocs to point out that
for the best behavior, users need to use "new FooAnalyzer(5.3)"
...leaving us in a position where "people who don't care about back compat
(e.g. just prototyping)" will in fact "have to deal with the horribly complex
versioning system." in order to get the best possible recommended behavior from
the analyzer.
...is that really what you suggest moving forward?
----
bq. I'm not going to revert it. You just want to make Lucene harder to use, so
more people will use apache solr instead.
I'm making arguments about the merrits of an API that leaves room for future
changes, while supporting _your_ (initial) proposal to simplify the Java API
for new users.
If you truly believe that I would argue a position with the primary motivation
of making/keeping an API (_any_ API) hard to use, then you should be asking the
PMC to remove me -- because anyone who would act with that kind of intentional
malice towards any part of the code base doesn't deserve to have commit
privileges.
If that's really what you think of me then apparently you don't know me as well
as i thought -- the fact that you would even type that sentence makes it
extremely clear to me that i don't know you as well as i thought.
Frankly, aside from school yard taunts as a kid, that's the most hurtful
comment i can ever remember being directed at me. If a stranger had made that
comment I wouldn't care and could easily brush it off, but from someone i
admire and respect ... that really fucking sucks.
Fuck you too Rob. Fuck you too.
----
I'm done with this issue, i won't be reading anymore comments from it...
https://people.apache.org/~hossman/#personal
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
