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