I was confused (still learning the ropes) but are others? Our back
compatibility states that when we deprecate we will offer the transition
API - it doesn't appear hard lined, as it says "the strategy is", but it
seems like its probably something we should stick with. From what I
read, the only difference with 3.0 is that we can drop deprecated stuff
(and 1.x file formats).
In that case, 3.0 offers us nothing special right? A chance to drop some
cruft and little more?
I'm all for a 2.5 if we want to get our ducks in a row for 2.9.
+1 on starting a drive towards a release soon - if 2.9/3.0 is going to
hold that up, lets just put it off and do a 2.5.
- Mark
Michael McCandless wrote:
Any more thoughts on this...?
This seems like a big confusion (whether we can deprecate X without
introducing new API Y, in 2.9 -- I don't see how), at least for me,
holding up 2.9.
Mike
Michael McCandless wrote:
Grant Ingersoll wrote:
On Dec 14, 2008, at 6:54 AM, Michael McCandless wrote:
I'd also personally like to see 2.9 released sooner rather than later,
maybe earliesh next year?
I don't think we should hold up 2.9 for some of the big items below
(eg Fieldable/AbstractField/Field cleanup), especially if they have
not even been started yet.
Well, if they are going to be changed, they need to at least be
deprecated, right?
But we can't deprecate old APIs until we've added new APIs, in a
release?
2.9 has turned into a feature release, when that has never been the
plan.
Good point, though is that a problem? I suppose we could do a 2.5
release before 2.9, if so.
One question: I'm assuming after 2.9 is out, we would fairly quickly
follow that up with a 3.0 that has more or less just removed
deprecations?
(Vs doing alot of dev putting new features into 3.0 as well).
More comments below:
Grant Ingersoll wrote:
1. Splitting Index time Document from Search time Document per
Hoss' ideas on a variety of threads in the past. Something to the
gist of having an InputDocument and an OutputDocument (and maybe
an abstract Document for shared features) such that people
wouldn't be confused about calling index time things on Document
during search and vice versa.
Maybe don't hold 2.9 for this one? (There's been lots of
discussion, and also recently interesting discussion on adding type
safety to Document under LUCENE-831, but nothing yet concrete).
As I said above, I don't see how we can. Either it gets deprecated
now (note, we don't have to have the new version now) or it doesn't
get changed for 3.x is my understanding of the process.
OK I guess I don't understand the "note, we don't have to have the
new version now" -- was this done in the past? Ie in 1.9 we
deprecated APIs not knowing what the future migration path would be?
And then in 2.0 development the replacement was completed & available
& deprecated APIs were then removed?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
