[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-25 Thread Ryan Ernst (JIRA)

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

Ryan Ernst commented on LUCENE-5859:


Yes, thanks.  I added 4.10 to Fix Versions.

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-25 Thread Jun Ohtani (JIRA)

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

Jun Ohtani commented on LUCENE-5859:


I think this ticket is Fix Version 4.10 too, right?

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-22 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619694 from [~sar...@syr.edu] in branch 'dev/trunk'
[ https://svn.apache.org/r1619694 ]

LUCENE-5859: Remove Version.LUCENE_CURRENT from code generated by htmlentity.py

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-21 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619625 from [~sar...@syr.edu] in branch 'dev/trunk'
[ https://svn.apache.org/r1619625 ]

LUCENE-5859: Remove Version.LUCENE_CURRENT from htmlentity.py code generator 
for HTMLStripCharFilter

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-21 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619623 from [~sar...@syr.edu] in branch 'dev/trunk'
[ https://svn.apache.org/r1619623 ]

LUCENE-5859, LUCENE-5871: Remove Version.LUCENE_CURRENT from javadocs

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-21 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619468 from [~rjernst] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1619468 ]

LUCENE-5859: Update changes entry to reflect backport

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-21 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619467 from [~rjernst] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1619467 ]

LUCENE-5859: Update changes entry to reflect backport

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-21 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619466 from [~rjernst] in branch 'dev/trunk'
[ https://svn.apache.org/r1619466 ]

LUCENE-5859: Update changes entry to reflect backport

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-20 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1619283 from [~rjernst] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1619283 ]

LUCENE-5859: Add Analyzer constructors without Version parameter and deprecate 
those taking Version

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-15 Thread Ryan Ernst (JIRA)

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

Ryan Ernst commented on LUCENE-5859:


I'm going to try and backport this to 4x (leaving the old ctors taking Version 
as deprecated).

> Remove Version from Analyzer constructors
> -
>
> Key: LUCENE-5859
> URL: https://issues.apache.org/jira/browse/LUCENE-5859
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Ryan Ernst
> Fix For: 5.0
>
> Attachments: LUCENE-5859.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on LUCENE-5859:
-

Commit 1616901 from [~rjernst] in branch 'dev/trunk'
[ https://svn.apache.org/r1616901 ]

LUCENE-5859: Remove Version from Analyzer constructors

> Remove Version from Analyzer constructors
> -
>
> 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.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-07 Thread Ryan Ernst (JIRA)

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

Ryan Ernst commented on LUCENE-5859:


I plan to commit this Friday morning PST if there are no objections.

> Remove Version from Analyzer constructors
> -
>
> 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.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-05 Thread Ryan Ernst (JIRA)

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

Ryan Ernst commented on LUCENE-5859:


Thanks [~thetaphi], I will indeed use your patch as a base there.

[~shaie], I created LUCENE-5871 to separately address IWC issues for Version.

> Remove Version from Analyzer constructors
> -
>
> 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.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-05 Thread Shai Erera (JIRA)

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

Shai Erera commented on LUCENE-5859:


I think we can apply the same approach here to IndexWriterConfig. If it's too 
much work, we can do it in a separate issue.

> Remove Version from Analyzer constructors
> -
>
> 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.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-05 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-5859:
---

bq. Note this is only the Analyzer side of that proposal. I will work on 
consolidating Version and LUCENE_MAIN_VERSION separately.

Thanks. There is already a patch going in that direction at LUCENE-5850. You 
can use it as basis for the refactoring. At least use the parts that cleans up 
common-build.xml and the testcase that checks that the LUCENE_MAIN_VERSION is 
identical to the one in common-build.xml.

> Remove Version from Analyzer constructors
> -
>
> 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.patch, 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



[jira] [Commented] (LUCENE-5859) Remove Version from Analyzer constructors

2014-08-04 Thread Ryan Ernst (JIRA)

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

Ryan Ernst commented on LUCENE-5859:


Note this is only the Analyzer side of that proposal.  I will work on 
consolidating Version and LUCENE_MAIN_VERSION separately.

> Remove Version from Analyzer constructors
> -
>
> 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.patch, 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