lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Proposal about Version API "relaxation"
Date Thu, 22 Apr 2010 21:58:13 GMT
Well yes - throwing out stable releases and back compat is going to be 
much more easy to maintain, but I think that's besides the point...

Handling our current back compat policy is not something most have 
wanted to do for long either - that's never been a reason for tossing it.

I agree with back porting as necessary, as long as necessary means every 
change that doesn't make sense to only go into unstable.

>>  Besides, it is essentially what we do now, minus back compat. maintenance on trunk.

Exactly - it essentially amounts to just throwing out back compat to a large degree. Stable
will be a joke - its just the last trunk release - no different than what we do now, but we
abandon back compat. That's a huge mistake IMO.



On 4/22/10 5:49 PM, Grant Ingersoll wrote:
> Jumping in late, but I have a hard time believing that committing to both trunk and stable
is something people are going to want to do in practice for very long.  The other proposal
(backporting when necessary) seems much more viable and easy to maintain and allows trunk
to move ahead.  Besides, it is essentially what we do now, minus back compat. maintenance
on trunk.  The tricky part is how to develop a back compat layer on the branches each time
that works effectively.
>
> -Grant
>
> On Apr 22, 2010, at 3:26 PM, Earwin Burrfoot wrote:
>
>    
>>> My main problem with devleoping new features on trunk first and then porting
>>> by adding backwards cruft is, that you first don’t care with backwards and
>>> then suddenly have to think about it. This may change the API on trunk
>>> again, to get nearer to backwards or maybe because a backwards layer is not
>>> possible. E.g. at the beginning of AttributeSource-TokenStream API, when
>>> Michael and me discussed about the sophisticated® backwards layer, we also
>>> did some changes to the new TokenStream API, to support backwards better.
>>>        
>> I agree with Robert here. The whole damn point of unstable trunk is to
>> allow developers to NOT think about backwards-compatibility, and think
>> about best possible API instead.
>>
>> Backwards-compatibility is a sin, a necessary sin, but a sin
>> nonetheless. Each time you have such impure thoughts, you should
>> cleanse your soul by confessing at your local JUG.
>>
>> -- 
>> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
>> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
>> ICQ: 104465785
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>      
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>    


-- 
- Mark

http://www.lucidimagination.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message