river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Release versioning
Date Fri, 02 Oct 2009 00:54:08 GMT
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.

View raw message