DM Smith wrote:
Generally open source projects have a policy to change as little of
the file
as possible, only changing what is necessary.
Hmmm. Necessary by what criterion? Necessary to make, say, Lucene
exploit the new interator constructs to avoid run-time type-checking?
Necessary to make the code more readable? Necessary to prevent use
with Java 1.4? :-)
I'm not sure I've ever seen a policy expressed in that way -- patches
generally should be clear, concise and do what they're intended to do,
but that doesn't necessarily mean minimising the size of the patch and
it doesn't necessarily mean keeping the source compatible with some old
compiler or environment.
Indeed, to be hypothetical and not entirely off-topic, it easy to
imagine two patches that are better than one. For the two patches,
reorganise a class so that it exploits Java 1.5 features and the "real"
patch that uses that new structure to cleanly and elegantly implement
some new feature. For the one patch, leave the code compatible with
1.4, but the functional patch is now much larger, more complex and
harder to verify.
It's possible that such a hypothetical patch (or pair of patches) is at
the core of the question of this thread. Does one embrace new language
features because they provide some tangible benefit to the
maintainability, functionality or complexity of the code? If so, for
how long? Should Lucene development freeze at 1.4 until there's no
working hardware that runs 1.4? Would that also preclude changes to
Lucene that make it work dramatically better on a machine with the
current de-facto "standard" memory? What happens when that's, say, 4Gb
and some old hardware simply won't let you install that much memory?
Would it not be better to freeze application development that needs an
old environment and simply back-port bug fixes and, where it makes
sense, functionality to the version of Lucene that is used in that
environment?
The approach taken by Red Hat with their Enterprise Linux series is that
they'll support a version of the platform for several years,
back-porting bug fixes, adding small, incremental functional changes and
so on. That means that this antique computer that happily runs RHEL3
will be able to carry on running an OS and applications that work on
that hardware until it finally gives p the ghost .
jch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
