lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Lucene 2.9 and deprecated methods
Date Sat, 03 Oct 2009 10:58:24 GMT

On Oct 2, 2009, at 7:33 PM, Michael McCandless wrote:

> Sigh.  The introduction of new but deprecated methods is silly.  Is
> there some simple automated way to catch/prevent these?
> The proliferation of ctors/factory methods is a nightmare.

Ah, so yet again, we are trying to work around a problem that is due  
to the ridiculousness of how we manage releases and deprecations and  
not necessarily something that is technically wrong.  It's not like  
this is news.  I've been complaining about the # of ctors for a long  
time (try training people on this stuff and you'll know what I mean).   
I'm not trying to be antagonistic, but if we would all just face facts  
that we do releases so few and far between that I just don't see it as  
being some massive hardship to remove some deprecations more often  
than every major release.   It's funny, we add things in an agile way  
and everyone loves that, but we remove them in such a drawn out and  
monolithic manner that it is mind-boggling.  We induce way more  
confusion than we prevent.  Any sane programmer out there has to do  
more than just drop in any release, no matter what, (in other words,  
the whole drop in back compat thing is a myth, so get over it) and as  
soon as they start looking at the myriad of options, they are going to  
be confused.  Far better for us just to remove an inferior method,  
with some smaller amount of warning, than to leave them guessing.  Not  
only that, but as is evidenced by the new Token stuff, using  
deprecated and new stuff together may be even worse than just getting  
rid of the old stuff.

Simply put, I propose we adopt a model we've all discussed many times  
before where we mark deprecated items with the version they will be  
removed in, regardless of minor/major number, with the caveat that it  
must be at least one more minor version (i.e. announce deprecation in  
2.4.0, remove in 2.5.0).  Major versions than are about what we all  
expect out of major versions from every other software package in the  
land:  major new features or near complete overhaul of existing  
functionality.  With this model, we won't have massive amounts of  
deprecation piling up, our users are still given plenty of warning  
whereby they can _plan_ for it, and we have more flexibility in how we  


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message