You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2014/07/30 22:38:39 UTC

[jira] [Comment Edited] (LUCENE-5859) Remove Version.java completely

    [ https://issues.apache.org/jira/browse/LUCENE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079922#comment-14079922 ] 

Uwe Schindler edited comment on LUCENE-5859 at 7/30/14 8:36 PM:
----------------------------------------------------------------

I think we should all calm down here. We are all strong personalities, so it is always a bit hard if different opinions crush against each other. I had the same problem today in LUCENE-5850, two different opinions. Yes, I am now disappointed, because I spent hard work on the issue and instead of looking at the key parts of the patch and the process of moving forward and improving the stuff, only quibbling around stupid ALPHA/BETA versions was the response - just disappointing. I don't think the other issue participant ever looked at the patch, he just read what I wrote down as patch description and then did not like it because of a small detail. I just stopped working on the issue and maybe I will work on it tomorrow, maybe.

We should stop heavy committing here and all calm down!

bq. Veto must have technical justification. Good luck with the technical justification of me not removing dead code.

There is indeed a technical justification: The Version parameter may be useless now, but once we add new features to StandardAnalyzer, the Version parameter gets useful again, so we need to re-add it - leading to the known backwards problems. This again brings the problem that uses, who started at 5.0 will not have a defined value for it in 5.1 and then we have problems. In my personal opinion, every Analyzer must have the Version parameter mandatory.

On the other hand I know the problems with the mandatory parameter. I have seen users tripping in the same trap like without the parameter: Once they upgrade Lucene, they just search/replace every occurence of the old Version parameter, just to get the "latest and best features" (documentation) and to remove deprecations, because all previous versions are deprecated. But they don't reindex - and boom they have the same problem like without the parameter. So it had no good effect. Other projects like Elasticsearch don't care about the version parameter. They have a global static constant in every release. Users just upgrade - boom, same problem.

In my opinion, the documentation is much too general. We should only ever use Version in the analyzers. Version should also be only part of the Analyzers module, not Lucene core. In my opinion - and I agree with Robert - it is only useful there! And in the analysis moudle it should be correctly documented, why it is there and what it does. And why it is wrong to just use the latest and best without reindexing.


was (Author: thetaphi):
I think we should all calm down here. We are all strong personalities, so it is always a bit hard if different opinions crush against each other. I had the same problem today in LUCENE-5850, two different opinions. Yes, I am now disappointed, because I spent hard work on the issue and instead of looking at the key parts of the patch and the process of moving forward and improving the stuff, only quibbling around stupid ALPHA/BETA versions was the response - just disappointing. I just stopped working on the issue and maybe I will work on it tomorrow, just maybe.

We should stop heavy committing here and all calm down!

bq. Veto must have technical justification. Good luck with the technical justification of me not removing dead code.

There is indeed a technical justification: The Version parameter may be useless now, but once we add new features to StandardAnalyzer, the Version parameter gets useful again, so we need to re-add it - leading to the known backwards problems. This again brings the problem that uses, who started at 5.0 will not have a defined value for it in 5.1 and then we have problems. In my personal opinion, every Analyzer must have the Version parameter mandatory.

On the other hand I know the problems with the mandatory parameter. I have seen users tripping in the same trap like without the parameter: Once they upgrade Lucene, they just search/replace every occurence of the old Version parameter, just to get the "latest and best features" (documentation) and to remove deprecations, because all previous versions are deprecated. But they don't reindex - and boom they have the same problem like without the parameter. So it had no good effect. Other projects like Elasticsearch don't care about the version parameter. They have a global static constant in every release. Users just upgrade - boom, same problem.

In my opinion, the documentation is much too general. We should only ever use Version in the analyzers. Version should also be only part of the Analyzers module, not Lucene core. In my opinion - and I agree with Robert - it is only useful there! And in the analysis moudle it should be correctly documented, why it is there and what it does. And why it is wrong to just use the latest and best without reindexing.

> 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