I just don't see how we will ever get to 3.0 if we continue this
path. People don't seem interested in much beyond new features and
bug fixes, so if we're going to do this 2.9 to 3.0 thing, I think we
need to go for it a bit more wholeheartedly and say that 2.9 truly is
not going to have any new features and is solely going to be about
deprecation. Thus, we should be able to do 2.5 and then soon
thereafter do 2.9, otherwise the urge to "fix and extend" will always
be there.
I personally think it's possible to deprecate w/o having to say what
the new thing is going to look like, in some cases. A major release
should be an opportunity to clean up and improve, but we shouldn't
have to decide all of it immediately. We know what we don't like, but
that doesn't mean we necessarily have what we do like decided on. I
think it's too much of a burden.
-Grant
On Dec 18, 2008, at 8:54 PM, Mark Miller wrote:
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
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
