You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2008/07/30 14:44:00 UTC
[VOTE] Break Back Compatibility "Contract" on Fieldable
As they say, rules are meant to be broken...
For a variety of reasons, some outlined below, I (and others) would
like us to break our back compatibility requirements and allow for
modifying the Fieldable interface in 2.x releases with the 3.x plan to
be to separate out write side interfaces from read side interfaces per
Hoss' suggestion in http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
.
Our reasons are based on LUCENE-1340, LUCENE-1219 and http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
Simply put, my gut says there are almost no implementations of
Fieldable "in the wild", and those that are won't mind a few lines of
code change here and there to accommodate Fieldable changing (since
Fields really are just simple data structures and don't due much
algorithmically, except maybe LazyField)
Thus, here's the vote part:
1. We mark Fieldable as being subject to change. We heavily advertise
(on java-dev and java-user and maybe general) that in the next minor
release of Lucene (2.4), Fieldable will be changing. It is also
marked at the top of CHANGES.txt very clearly for all the world to
see. Since 2.4 is probably at least a month away, I think this gives
anyone with a pulse enough time to react.
2. We thus allow 1340 and 1219 to go forward, and maybe some others.
3. [OPTIONAL] We commit to rethinking input Documents and output
Documents for 3.x per Hoss' design suggestions in the email thread
above. At a minimum, it becomes an abstract base class.
+1 to all 3 items from me.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Break Back Compatibility "Contract" on Fieldable
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
+1 to all three from me. Darn you, Java, for making object-
orientation kludgey.
Erik
On Jul 30, 2008, at 8:44 AM, Grant Ingersoll wrote:
> As they say, rules are meant to be broken...
>
> For a variety of reasons, some outlined below, I (and others) would
> like us to break our back compatibility requirements and allow for
> modifying the Fieldable interface in 2.x releases with the 3.x plan
> to be to separate out write side interfaces from read side
> interfaces per Hoss' suggestion in http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
> .
>
> Our reasons are based on LUCENE-1340, LUCENE-1219 and http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
>
> Simply put, my gut says there are almost no implementations of
> Fieldable "in the wild", and those that are won't mind a few lines
> of code change here and there to accommodate Fieldable changing
> (since Fields really are just simple data structures and don't due
> much algorithmically, except maybe LazyField)
>
> Thus, here's the vote part:
>
> 1. We mark Fieldable as being subject to change. We heavily
> advertise (on java-dev and java-user and maybe general) that in the
> next minor release of Lucene (2.4), Fieldable will be changing. It
> is also marked at the top of CHANGES.txt very clearly for all the
> world to see. Since 2.4 is probably at least a month away, I think
> this gives anyone with a pulse enough time to react.
>
> 2. We thus allow 1340 and 1219 to go forward, and maybe some others.
>
> 3. [OPTIONAL] We commit to rethinking input Documents and output
> Documents for 3.x per Hoss' design suggestions in the email thread
> above. At a minimum, it becomes an abstract base class.
>
>
> +1 to all 3 items from me.
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Break Back Compatibility "Contract" on Fieldable
Posted by Michael McCandless <lu...@mikemccandless.com>.
+1 to all three.
Mike
Grant Ingersoll wrote:
> As they say, rules are meant to be broken...
>
> For a variety of reasons, some outlined below, I (and others) would
> like us to break our back compatibility requirements and allow for
> modifying the Fieldable interface in 2.x releases with the 3.x plan
> to be to separate out write side interfaces from read side
> interfaces per Hoss' suggestion in http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
> .
>
> Our reasons are based on LUCENE-1340, LUCENE-1219 and http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
>
> Simply put, my gut says there are almost no implementations of
> Fieldable "in the wild", and those that are won't mind a few lines
> of code change here and there to accommodate Fieldable changing
> (since Fields really are just simple data structures and don't due
> much algorithmically, except maybe LazyField)
>
> Thus, here's the vote part:
>
> 1. We mark Fieldable as being subject to change. We heavily
> advertise (on java-dev and java-user and maybe general) that in the
> next minor release of Lucene (2.4), Fieldable will be changing. It
> is also marked at the top of CHANGES.txt very clearly for all the
> world to see. Since 2.4 is probably at least a month away, I think
> this gives anyone with a pulse enough time to react.
>
> 2. We thus allow 1340 and 1219 to go forward, and maybe some others.
>
> 3. [OPTIONAL] We commit to rethinking input Documents and output
> Documents for 3.x per Hoss' design suggestions in the email thread
> above. At a minimum, it becomes an abstract base class.
>
>
> +1 to all 3 items from me.
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Break Back Compatibility "Contract" on Fieldable
Posted by Grant Ingersoll <gs...@apache.org>.
OK, this vote has passed. I will open an issue and provide a patch.
-Grant
On Jul 30, 2008, at 8:44 AM, Grant Ingersoll wrote:
> As they say, rules are meant to be broken...
>
> For a variety of reasons, some outlined below, I (and others) would
> like us to break our back compatibility requirements and allow for
> modifying the Fieldable interface in 2.x releases with the 3.x plan
> to be to separate out write side interfaces from read side
> interfaces per Hoss' suggestion in http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
> .
>
> Our reasons are based on LUCENE-1340, LUCENE-1219 and http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
>
> Simply put, my gut says there are almost no implementations of
> Fieldable "in the wild", and those that are won't mind a few lines
> of code change here and there to accommodate Fieldable changing
> (since Fields really are just simple data structures and don't due
> much algorithmically, except maybe LazyField)
>
> Thus, here's the vote part:
>
> 1. We mark Fieldable as being subject to change. We heavily
> advertise (on java-dev and java-user and maybe general) that in the
> next minor release of Lucene (2.4), Fieldable will be changing. It
> is also marked at the top of CHANGES.txt very clearly for all the
> world to see. Since 2.4 is probably at least a month away, I think
> this gives anyone with a pulse enough time to react.
>
> 2. We thus allow 1340 and 1219 to go forward, and maybe some others.
>
> 3. [OPTIONAL] We commit to rethinking input Documents and output
> Documents for 3.x per Hoss' design suggestions in the email thread
> above. At a minimum, it becomes an abstract base class.
>
>
> +1 to all 3 items from me.
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Break Back Compatibility "Contract" on Fieldable
Posted by Michael Busch <bu...@gmail.com>.
+1 to all three items. This is good stuff.
-Michael
Grant Ingersoll wrote:
> As they say, rules are meant to be broken...
>
> For a variety of reasons, some outlined below, I (and others) would like
> us to break our back compatibility requirements and allow for modifying
> the Fieldable interface in 2.x releases with the 3.x plan to be to
> separate out write side interfaces from read side interfaces per Hoss'
> suggestion in
> http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField.
>
>
> Our reasons are based on LUCENE-1340, LUCENE-1219 and
> http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
>
>
> Simply put, my gut says there are almost no implementations of Fieldable
> "in the wild", and those that are won't mind a few lines of code change
> here and there to accommodate Fieldable changing (since Fields really
> are just simple data structures and don't due much algorithmically,
> except maybe LazyField)
>
> Thus, here's the vote part:
>
> 1. We mark Fieldable as being subject to change. We heavily advertise
> (on java-dev and java-user and maybe general) that in the next minor
> release of Lucene (2.4), Fieldable will be changing. It is also marked
> at the top of CHANGES.txt very clearly for all the world to see. Since
> 2.4 is probably at least a month away, I think this gives anyone with a
> pulse enough time to react.
>
> 2. We thus allow 1340 and 1219 to go forward, and maybe some others.
>
> 3. [OPTIONAL] We commit to rethinking input Documents and output
> Documents for 3.x per Hoss' design suggestions in the email thread
> above. At a minimum, it becomes an abstract base class.
>
>
> +1 to all 3 items from me.
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Break Back Compatibility "Contract" on Fieldable
Posted by Grant Ingersoll <gs...@apache.org>.
On Jul 30, 2008, at 11:07 AM, DM Smith wrote:
>
> I'm not sure that the comment that "this gives anyone with a pulse
> enough time to react" is particularly accurate or helpful. It all
> depends upon effective communication (such as to Lucene user's
> mailing list and package maintainers).
It was mostly meant tongue in cheek... The fact is, releases are few
and far between in Lucene world, usually 6 mos or more and are hashed
over for a long time before that. I think that is plenty of time for
even the strictest of organizations to make a decision on what to do
in regards to upgrading (which is never required).
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Break Back Compatibility "Contract" on Fieldable
Posted by DM Smith <dm...@gmail.com>.
As a user, I have no problem with this, as I have a pulse:)
If I understand that it just breaks software backward compatibility and
not compatibility with the index itself. Minor software changes are no
big deal to me. I would still expect that a newer API would still read
earlier indexes. Specifically that in the N series that N.x would be
able to read N.(x-1) and N.x would be able to read (N-1).y.
There needs to be a mechanism to communicate that a break has happened.
The current mechanism of @deprecated works well but requires several
releases to do the communication. This is both good and bad.
Also, in the RPM world, dependencies are typically noted as >= x && < y
(e.g. Lucene >= 2.0 && Lucene < 3.0). Also, a typical RPM will treat
minor numbers as a reason for replacement (e.g. Lucene 2.4.0 replaces
2.3.2) but that major numbers live independently (e.g. Lucene 2.3.2 and
3.0 live side by side). Such a policy as being suggested here
potentially makes managing a Lucene RPM more difficult. And it may
invalidate existing ones. The same might be true with other Linux
package manager files such as Debian's.
If the change is seen merely as an internal implementation detail that
would affect very few, then this is probably a nit.
I'm not sure that the comment that "this gives anyone with a pulse
enough time to react" is particularly accurate or helpful. It all
depends upon effective communication (such as to Lucene user's mailing
list and package maintainers).
-- DM Smith
Grant Ingersoll wrote:
> As they say, rules are meant to be broken...
>
> For a variety of reasons, some outlined below, I (and others) would
> like us to break our back compatibility requirements and allow for
> modifying the Fieldable interface in 2.x releases with the 3.x plan to
> be to separate out write side interfaces from read side interfaces per
> Hoss' suggestion in
> http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField.
>
>
> Our reasons are based on LUCENE-1340, LUCENE-1219 and
> http://lucene.markmail.org/message/77qs2pjy3inzfddj?q=Fieldable%2C+AbstractField
>
>
> Simply put, my gut says there are almost no implementations of
> Fieldable "in the wild", and those that are won't mind a few lines of
> code change here and there to accommodate Fieldable changing (since
> Fields really are just simple data structures and don't due much
> algorithmically, except maybe LazyField)
>
> Thus, here's the vote part:
>
> 1. We mark Fieldable as being subject to change. We heavily advertise
> (on java-dev and java-user and maybe general) that in the next minor
> release of Lucene (2.4), Fieldable will be changing. It is also
> marked at the top of CHANGES.txt very clearly for all the world to
> see. Since 2.4 is probably at least a month away, I think this gives
> anyone with a pulse enough time to react.
>
> 2. We thus allow 1340 and 1219 to go forward, and maybe some others.
>
> 3. [OPTIONAL] We commit to rethinking input Documents and output
> Documents for 3.x per Hoss' design suggestions in the email thread
> above. At a minimum, it becomes an abstract base class.
>
>
> +1 to all 3 items from me.
>
> -Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org