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 personally always think about possible problems for implementing a backwards layer first. But of course for features like flex, that will never be backported, thinking about backwards layer is not needed, just hack and reinvent everyting! Uwe ----- 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:11 PM To: dev@lucene.apache.org Subject: Re: Proposal about Version API "relaxation" On Thu, Apr 22, 2010 at 10:08 AM, Earwin Burrfoot <ear...@gmail.com> wrote: Okay, let's live with parallel development, but make sure we 'always' port things from stable to trunk, and 'always' remove possible back-compat layers when doing such a port? Why wouldnt you commit to trunk, then merge to the stable branch? This could be nice for some patches, as you could first introduce the patch without back compat shims and make for easier review. -- Robert Muir rcm...@gmail.com