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

Reply via email to