But you need one, if you want to backwport some feature. My point was, that if you are planning to backport something, its better to start developing on stable, as else you can possibly get problems when you only have a clean API without any idea how to implement a backwards.
So for features that should be backported, start to plan with backwards in mind from the beginning. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: u...@thetaphi.de From: Robert Muir [mailto:rcm...@gmail.com] Sent: Thursday, April 22, 2010 4:53 PM To: dev@lucene.apache.org Subject: Re: Proposal about Version API "relaxation" On Thu, Apr 22, 2010 at 10:48 AM, Uwe Schindler <u...@thetaphi.de> wrote: Hi Robert, 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 think with this proposal things like sophisticated(R) backwards layers would generally become a thing of the past... -- Robert Muir rcm...@gmail.com
