If they are " no longer actively developing the portion of the code
that's broken, aren't seeking the new feature, etc", and they stay
back on old versions... isn't that exactly what we want? They can
stay on the old version, and new application development uses the
newer version.
It would be different if it was a core JRE interface or similar -
this is an optional jar.
Part of what always made Windows so fragile is that as it evolved
they tried to maintain backward compatibility - making working with
the old/new code and fixing bugs almost impossible. The bloat became
impossible to deal with.
I bet, if you did a poll of all Lucene users, you would find a
majority of them still only run 1.4.3, or maybe 1.9. Even with 2.0,
2.3, or 3.0, that is still going to be the case.
As always, JMO.
On Jan 17, 2008, at 3:14 PM, Doug Cutting wrote:
Grant Ingersoll wrote:
1. We add a new section to CHANGES for each release, at the top
where we can declare what deprecations will be removed in the
_next_ release (major or minor) and also any interface API changes
2. When deprecating, the @deprecate tag should declare what
version it will be removed in and that version must be one greater
than the next targeted release. That is, if the next release is
2.4, then anything deprecated in 2.3 is game to be removed in 2.9.
This would mean that one could never simply drop in the new jar and
expect things to still work, which is something that we currently
try to guarantee. That's a significant thing to give up, in terms
of usability. In my experience, folks hate incompatible changes,
since they're frequently no longer actively developing the portion
of the code that's broken, aren't seeking the new feature, etc.
This is why lots of folks stay back on old versions.
In terms of benefits, this would permit us to evolve APIs more
rapidly. So it pits external usability against API evolution
speed, with no clear winner. +0
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
