[
https://issues.apache.org/jira/browse/LUCENE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1084:
---
Fix Version/s: (was: 2.4)
3.0
> increase default maxFieldLeng
[
https://issues.apache.org/jira/browse/LUCENE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559887#action_12559887
]
Michael McCandless commented on LUCENE-1084:
{quote}
This kind of limit is com
[
https://issues.apache.org/jira/browse/LUCENE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559888#action_12559888
]
Michael McCandless commented on LUCENE-1136:
It works like a charm! And, all
[
https://issues.apache.org/jira/browse/LUCENE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-1136:
Attachment: lucene-1136.patch
Good catch!
This patch fixes that - printing the '-' for tasks with
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reopened LUCENE-1050:
-
Assignee: Grant Ingersoll (was: Michael McCandless)
Lucene Fields: (was: [New
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559908#action_12559908
]
Grant Ingersoll commented on LUCENE-1050:
-
I agree, it can be fixed by the SpellCh
I have been thinking for a while that is time we revisit our back-
compatibility "policy" (http://wiki.apache.org/lucene-java/BackwardsCompatibility
) in terms of maybe becoming a little leaner and also in terms of
addressing some issues that come up from time to time in relation to
bug fixes
[
https://issues.apache.org/jira/browse/LUCENE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-1138:
---
Assignee: Grant Ingersoll
> SpellChecker.clearIndex calls unlock inappropriately
> -
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1050:
Comment: was deleted
> SimpleFSLockFactory ignores error on deleting the lock file
> -
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1050:
Attachment: (was: LUCENE-1050-2.patch)
> SimpleFSLockFactory ignores error on deleting
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1050:
Attachment: LUCENE-1050-2.patch
Patch for SimpleLock
> SimpleFSLockFactory ignores error
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559919#action_12559919
]
Michael McCandless commented on LUCENE-1050:
I agree, we should fix it so that
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559916#action_12559916
]
Grant Ingersoll commented on LUCENE-1050:
-
Hmm, it seems putting in lockFile.exist
[
https://issues.apache.org/jira/browse/LUCENE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1138:
Attachment: LUCENE-1138.patch
Here's the fix for the spellchecker. I confirmed this fixes
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559927#action_12559927
]
Michael McCandless commented on LUCENE-1050:
{quote}
Grant, you just have to c
[
https://issues.apache.org/jira/browse/LUCENE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559932#action_12559932
]
Grant Ingersoll commented on LUCENE-1138:
-
I will commit around 12 EST today.
> S
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1050:
Attachment: LUCENE-1050-2.patch
OK, this patch works and passes the test. I will commit t
On Jan 17, 2008, at 1:38 AM, Chris Hostetter wrote:
: If I remember right, the file format changed in 2.1, such that 2.0
could not
: read a 2.1 index.
that is totally within the bounds of the compatibility statement...
http://wiki.apache.org/lucene-java/BackwardsCompatibility
Note that ol
See http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/340/changes
--
started
ERROR: svn: PROPFIND request failed on '/repos/asf/lucene/java/trunk'
svn: Connection timed out
org.tmatesoft.svn.core.SVNException: svn: PROPFIND request failed on
'/r
[
https://issues.apache.org/jira/browse/LUCENE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-1084:
Lucene Fields: [New, Patch Available] (was: [New])
> increase default maxFieldLength?
> -
[
https://issues.apache.org/jira/browse/LUCENE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-1084:
Attachment: LUCENE-1084.patch
Attaching a patch implementing my suggestion to add an explicit maxi
[
https://issues.apache.org/jira/browse/LUCENE-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1002.
-
Resolution: Fixed
Lucene Fields: (was: [New])
> Nightly Builds
> --
[
https://issues.apache.org/jira/browse/LUCENE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1138.
-
Resolution: Fixed
Lucene Fields: (was: [New])
Committed on 612869 and 612868 (b
[
https://issues.apache.org/jira/browse/LUCENE-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1050.
-
Resolution: Fixed
Committed on 612869 and 612868 (branch and trunk)
> SimpleFSLockFacto
Hi Grant,
do you think we need another RC today so that people can test this.
Otherwise I'll create a (hopefully) final RC end of tomorrow and call a
release vote.
-Michael
[EMAIL PROTECTED] wrote:
> Author: gsingers
> Date: Thu Jan 17 09:01:01 2008
> New Revision: 612869
>
> URL: http://svn.
Hmmm. The functionality that caused the problem was introduced in
2.3, so 2.2 users would not be aware of it. I'm pretty confident it
is right, but...
I am definitely fine w/ the SpellChecker change, as it should have
been checking isLocked in the first place. The Lock stuff, I will
ha
Grant Ingersoll wrote:
>
> What do others think?
>
> I think I will say +1 to going ahead w/ the release.
>
I agree. The patch seems low-risk to me.
-Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
> Examples of the former issue include things like removing
> deprecations sooner and the ability to add new methods to interfaces
> (both of these are not to be done ad-hoc)
What would be the difference between ad-hoc and non-ad-hoc?
Bill
On Jan 17, 2008, at 2:42 PM, Bill Janssen wrote:
Examples of the former issue include things like removing
deprecations sooner and the ability to add new methods to interfaces
(both of these are not to be done ad-hoc)
What would be the difference between ad-hoc and non-ad-hoc?
Maybe bad ch
Grant Ingersoll wrote:
1. We add a new section to CHANGES for each release, at the top where we
can declare what deprecations will be removed in the _next_ release
(major or minor) and also any interface API changes
2. When deprecating, the @deprecate tag should declare what version it
will be
On Jan 17, 2008, at 4:14 PM, Doug Cutting wrote:
Grant Ingersoll wrote:
1. We add a new section to CHANGES for each release, at the top
where we can declare what deprecations will be removed in the
_next_ release (major or minor) and also any interface API changes
2. When deprecating, the
Hi Grant,
On 01/17/2008 at 7:51 AM, Grant Ingersoll wrote:
> Our minor release cycles are currently in the 3-6 months range
> and our major release cycles are in the 1-1.5 year range.
Since 2.0.0, including 2.3.0 - assuming it will be released in the next week or
so - the minor release intervals
Grant Ingersoll wrote:
My reasoning for this solution: Our minor release cycles are
currently in the 3-6 months range and our major release cycles are in
the 1-1.5 year range. I think giving someone 4-8 (or whatever) months
is more than enough time to prepare for API changes. I am not sur
If they are " no longer actively developing the portion of the code
that's broken, aren't seeking the new feature, etc", and they stay
back on old versions... isn't that exactly what we want? They can
stay on the old version, and new application development uses the
newer version.
It woul
On Jan 17, 2008, at 7:57 PM, robert engels wrote:
If they are " no longer actively developing the portion of the code
that's broken, aren't seeking the new feature, etc", and they stay
back on old versions... isn't that exactly what we want? They can
stay on the old version, and new applic
I guess I am suggesting that instead of maintaining the whole major/
minor thing (not including file format) that we relax a bit and say
that any give feature we choose to remove or add has to go through two
release cycles, which according to your averages, would equal just
over 1 year's tim
On Jan 17, 2008, at 9:30 PM, DM Smith wrote:
On Jan 17, 2008, at 7:57 PM, robert engels wrote:
If they are " no longer actively developing the portion of the code
that's broken, aren't seeking the new feature, etc", and they stay
back on old versions... isn't that exactly what we want? Th
Hi Team,
great job - there are no severe issues in Jira with "Fix Version" 2.3.
As announced I will therefore build another Release Candidate tomorrow
(01/18/08) around 3pm PST and call a release vote if no blocking issues
will come up by then and if nobody objects.
So in case you want to check-i
Steven A Rowe wrote:
> Hi Michael,
>
> On 01/15/2008 at 10:04 PM, Michael Busch wrote:
>> which version of the maven-ant-tasks are you using?
>
> 2.0.8
>
> Steve
>
Hi Steve,
it's a bit weird. I actually just had the same problem with 2.0.8. Then
I switched back to 2.0.7 and 'ant generate-mave
See http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/341/changes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
18 jan 2008 kl. 03.39 skrev Grant Ingersoll:
Does anyone have experience w/ how other open source projects deal
with this?
Would be a pain to implement, but it could be done as libcompat.
lucene-2.4-compat-core-3.0.jar
--
karl
-
That brings us back to an earlier discussion: "if majority want to
break compatibility, then we should do so, and the minority can back-
port the changes to a previous release if they feel it is warranted."
I don't understand why that isn't a viable approach.
I agree that maintaining interfac
18 jan 2008 kl. 07.41 skrev robert engels:
Look at similar problems and how they handled in the JDK. The Date
class has been notorious since its inception. The Calendar class is
almost no better, now they are developing JSR-310 to replace both.
Existing code can still use the Date or Calen
That wasn't what I was thinking. They would use lucene23.jar if they
wanted the 2.3 API. Newer code uses the lucene30.jar for the 3.0 API.
The others could continue to back-port 3.0 features to 2.3.X if they
wished (and could do so without changing the API - private changes
only).
I thin
44 matches
Mail list logo
