lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Proposal about Version API "relaxation"
Date Thu, 22 Apr 2010 14:48:34 GMT
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 Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen




From: Robert Muir [] 
Sent: Thursday, April 22, 2010 4:11 PM
Subject: Re: Proposal about Version API "relaxation"



On Thu, Apr 22, 2010 at 10:08 AM, Earwin Burrfoot <> 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

Robert Muir

View raw message