On Dec 19, 2008, at 6:08 AM, Michael McCandless wrote:
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.
Hmm, OK. Didn't notice that, I just thought it was. Sounds good, then.
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?
Yes. I think Document is another case. Hoss has made the case for an
InputDoc and an OutputDoc.
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 don't know that is so much a concern about finishing it, but
something just might not even be possible in 2.9. For instance,
totally hypothetical: we deprecate something that we know we are
going to replace w/ a 1.5 feature.
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.
Which is the bigger hole, deciding it in 2.9 and publishing it and
therefore binding it for all of 3.x or just indicating we are going to
deprecate in 2.9?
FWIW, I also think we could choose to "un-deprecate" if we don't come
up w/ a better solution.
This isn't a big deal to me, I'm just trying to give us some
flexibility. I think sometimes we are so rigid about back
compatibility that it is hindering us. To me, a major release gives
us some wiggle room. Do I think we throw back compat out the window?
Of course not. Do I think it gives us some room to be less strict
about it? Yes.
I've said it before many times, and I think others have as well, given
the length of our release cycles (usually 6 months or more), I think
we give people more than enough time to react to changes. In this day
and age of intelligent refactoring tools and iterative development, I
don't think it is as great a burden. That being said, I'm not
advocating for unrestricted change at any point. I'd just like us not
to be so shackled by it at every turn. Seems to me, a move to a major
release is just one of those turns.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
