lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Proposal about Version API "relaxation"
Date Thu, 22 Apr 2010 21:49:57 GMT
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.


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/Кирилл Захаренко (
> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
> ICQ: 104465785
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message