Michael McCandless wrote:
On Tue, Jun 16, 2009 at 12:41 PM, DM Smith wrote:
The Debian policy is to bump the major revision number every time there is an
incompatible API change.
Does this include adding methods to interfaces? Ie, is there some
automated check done by Debian that ro
On Tue, Jun 16, 2009 at 12:41 PM, DM Smith wrote:
> The Debian policy is to bump the major revision number every time there is an
> incompatible API change.
Does this include adding methods to interfaces? Ie, is there some
automated check done by Debian that roughly matches our "JAR
drop-in-abi
On Tue, Jun 16, 2009 at 12:41 PM, DM Smith wrote:
> I'll reiterate what this means to me. It is more than just file format
> stability. An index must still be useful. An index is invalidated if the
> analyzers, filters and/or token streams produce a different result. If these
> change, the index i
On 6/16/09 9:41 AM, DM Smith wrote:
Perhaps you should go back and see why the thread died.
OK I will read it.
I think we should do the following:
I'll send the mentioned mail to the user list and wait for feedback.
After a decent amount of time for feedback I will call a vote on
java-dev w
Mark Miller wrote:
I'm inclined to agree to a large extent. If we want to remove
deprecations more often, why not release major versions more often?
The main ramification I see being that the index back compat period
could be significantly shortened time wise with the current policy.
I don't t
I'm inclined to agree to a large extent. If we want to remove
deprecations more often, why not release major versions more often?
The main ramification I see being that the index back compat period
could be significantly shortened time wise with the current policy.
DM Smith wrote:
Michael B
Michael Busch wrote:
Probably everyone is thinking right now "Oh no! Not again!". I admit I
didn't fully read the incredibly long recent thread about
backwards-compatibility, so maybe what I'm about to propose has been
proposed already. In that case my apologies in advance.
Perhaps you should go
Also, much shorter text to read :)
You're right, Michael's is 484 words, mine was 691. But in my defense, I did
offer two more changes, that were later brought up on this thread (summing
to 563 words) :).
Anyway, I'm glad it's kept alive and hopefully things will change.
Shai
On Tue, Jun 16, 20
I would guess you hit what I call "thread fatigue" by the time you
summed that up :)
Michael hasn't been around for a bit - perhaps it was easier for him to
spawn a new thread.
Also, much shorter text to read :)
Shai Erera wrote:
Ahh ... I wish I had finished
http://www.nabble.com/Re%3A-Luc
Well I'd actually hope that there will be significantly less need to do
these "tricks" to get around the new policy.
I'll open a JIRA issue and we can use it to work on the exact wording.
Michael
On 6/16/09 9:03 AM, Mark Miller wrote:
Right - I'm not saying that the users should trump the dev
Yeah, the only difference now is that we can remove deprecated APIs. And
I guess we add nothing.
Which is, as Micahel has said, is goofy.
3.0 will be 2.9 like 1.9 was 2.0. Without deprecations.
Not a big deal at all, but I find it goofy too.
- Mark
Michael Busch wrote:
From a backwards-comp
Ahh ... I wish I had finished
http://www.nabble.com/Re%3A-Lucene%27s-default-settings---back-compatibility-p23792927.htmlwith
+1 of my own. Guess that's what was missing to get it to closure :).
Shai
On Tue, Jun 16, 2009 at 7:03 PM, Michael Busch wrote:
> I'd suggest to treat a runtime change
Except regarding file format compatibility, see 1.
On 6/16/09 9:04 AM, Michael Busch wrote:
>From a backwards-compatibility point of view, nothing really.
Michael
On 6/16/09 8:59 AM, Yonik Seeley wrote:
So under this proposal, what's the difference between a major and minor release?
-Yonik
From a backwards-compatibility point of view, nothing really.
Michael
On 6/16/09 8:59 AM, Yonik Seeley wrote:
So under this proposal, what's the difference between a major and minor release?
-Yonik
http://www.lucidimagination.com
On Tue, Jun 16, 2009 at 6:37 AM, Michael Busch wrote:
Right - I'm not saying that the users should trump the devs, just
curious what the response will be, if any.
I also think that when we update the back compat policy, there should be
wording that stresses where we should use our new powers carefully (eg
common API's and such).
And we should u
Index back-compat is guaranteed to hold within minor releases.
On Tue, Jun 16, 2009 at 6:59 PM, Yonik Seeley wrote:
> So under this proposal, what's the difference between a major and minor
> release?
>
> -Yonik
> http://www.lucidimagination.com
>
>
>
> On Tue, Jun 16, 2009 at 6:37 AM, Michael Bu
I'd suggest to treat a runtime change like an API change (unless it's
fixing a bug of course),
i.e. giving a warning, providing a switch, switching the default
behavior only after a major
or minor release was around that had the warning/switch.
Michael
On 6/16/09 8:54 AM, Earwin Burrfoot wro
So under this proposal, what's the difference between a major and minor release?
-Yonik
http://www.lucidimagination.com
On Tue, Jun 16, 2009 at 6:37 AM, Michael Busch wrote:
> Probably everyone is thinking right now "Oh no! Not again!". I admit I
> didn't fully read the incredibly long recent t
Fair enough. We certainly want our users to understand our reasons for
these changes, and keep their trust that we're making our best efforts
to keep upgrading as effortless as possible.
However, there will always be someone who is not happy with such a
change. But if the vast majority of the
Oh yes! Again!
+1
One point is missing. What about incompatible behavioral changes that
do not touch API and file format?
Like posIncr=0 at the first token in stream, or analyzer fixes, or
something along these lines.
Are we free to introduce them in a minor release without warning, or
are we goi
Sounds good, Grant. I'll open a task to change the policy with target
release=3.0.
Michael
On 6/16/09 6:53 AM, Grant Ingersoll wrote:
+1 on everything. This is the sanity we need, especially #2. Thanks
for bringing this up again.
I'd add a slight mod to #2 that I think helps further comm
Wow this is *very* similar! :)
On 6/16/09 4:29 AM, Shai Erera wrote:
Since I proposed the same changes
(http://www.nabble.com/Re%3A-Lucene%27s-default-settings---back-compatibility-p23792927.html),
I can only give my +1 to all 4 :).
On the other thread I also proposed to change the policy aro
I'd be interested in what the users list has to say.
With this many +1's, seems reasonable to take it over there.
- Mark
Grant Ingersoll wrote:
+1 on everything. This is the sanity we need, especially #2. Thanks
for bringing this up again.
I'd add a slight mod to #2 that I think helps fur
+1 on everything. This is the sanity we need, especially #2. Thanks
for bringing this up again.
I'd add a slight mod to #2 that I think helps further communicate to
users our expectations (marked by my initials GSI) by employing some
convention in our @deprecated comments:
2. Deprecated
Just to cat call from the corner over here:
So unless you update on *every* minor release, from a users perspective,
this is the same as tossing out API back compat (though still with the
option to keep what we want around as long as we want) ?
Michael Busch wrote:
Probably everyone is think
+1 to all 4.
On Tue, Jun 16, 2009 at 2:07 PM, Michael
McCandless wrote:
> +1 to all 4.
>
> Mike
>
> On Tue, Jun 16, 2009 at 6:37 AM, Michael Busch wrote:
>> Probably everyone is thinking right now "Oh no! Not again!". I admit I
>> didn't fully read the incredibly long recent thread about
>> backwa
+1 to all 4.
Mike
On Tue, Jun 16, 2009 at 6:37 AM, Michael Busch wrote:
> Probably everyone is thinking right now "Oh no! Not again!". I admit I
> didn't fully read the incredibly long recent thread about
> backwards-compatibility, so maybe what I'm about to propose has been
> proposed already. I
Since I proposed the same changes (
http://www.nabble.com/Re%3A-Lucene%27s-default-settings---back-compatibility-p23792927.html),
I can only give my +1 to all 4 :).
On the other thread I also proposed to change the policy around changing
default settings. But maybe we should take it one step at a
Probably everyone is thinking right now "Oh no! Not again!". I admit I
didn't fully read the incredibly long recent thread about
backwards-compatibility, so maybe what I'm about to propose has been
proposed already. In that case my apologies in advance.
Rather than discussing our current backward
29 matches
Mail list logo
