Peter Firmstone wrote:
Niclas Hedhman wrote:
Peter,
I don't want to sound patronizing or "besser-wisser", but I disagree
with
your ambitions.
Major releases are an opportunity, where "clean up" should occur but
happen
as seldom as possible. Constraining such opportunity causes long-term
maintenance head-aches for the community which might drain it of the
little
energy that exists, IMHO pretty much the current state of River.
Now, if you formalizes your list of what is possible, I think we can
devise
strategy on how to make such changes without breaking source
compatibility
as well.
Chapter 13 of the Java Language specification third ed is a good place
to start. Attempting the above suggestion places additional
constraints on the changes possible, this would in fact make life more
difficult for the programmer to implement a new feature while
preserving backward compatibility. However if & when we determine
that we must break backward compatibility, we can at that point in
time, check to see if Binary compatibility is at least salvageable. I
would like to reserve the opportunity to determine if binary
compatibility can be salvaged after it has been determined that source
code compile time compatibility must be broken in order to achieve an
outcome. This constraint wouldn't apply until it has been deemed
necessary to break compile time compatibility.
Process:
1. It is deemed that compile time backward compatibility must be
broken to implement feature X.
2. Committers vote on adding of the feature.
3. If the vote outcome is in favour, then check if Binary
Compatibility can be preserved in the implementation.
4. If not then Binary compatibility is also broken.
Of course if preserving Binary Compatibility created a sub optimal
design, then as you suggest also dropping binary compatibility may also
be advantageous going forward.
