Grant Ingersoll wrote:

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.

Why can't 2.9 have new features as well as deprecation?  Looking back
in CHANGES.txt, 1.9 seems to have done that.

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.


Maybe a specific example can move this discussion forward:

We know we want to eventually refactor Fieldable/AbstractField/Field;
there's been lots of good discussion here but no concrete effort yet
to make it happen.  It's a very big change.

Are you saying we can deprecate these classes in 2.9, and all methods
whose signature involves one of these classes, without offering the
new classes?

But if we did that... wouldn't we then be forced into creating the new
classes for 3.0?  Is that that approach you're picturing?

I don't think that's realistic, because if we haven't started dev for
such a big change in 2.9, what makes us think in the 3.0 timeframe we
can finish it?  We'd be digging ourselves into a hole.

I guess my feeling is: if we do decide to block 2.9/3.0 release until
Fieldable/AbstractField/Field is fixed, I'd rather do it all in 2.9
(release the new APIs) than do it in 2 steps to avoid digging
ourselves into a hole.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to