lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: Back Compatibility
Date Fri, 18 Jan 2008 02:39:16 GMT
I guess I am suggesting that instead of maintaining the whole major/ 
minor thing (not including file format) that we relax a bit and say  
that any give feature we choose to remove or add has to go through two  
release cycles, which according to your averages, would equal just  
over 1 year's time.  If people can't adapt to a coming change that was  
announced a year ago, then I have to wonder why they need to upgrade  
at all. (OK, that is a little strong, but...)

And mind you, I am not set in stone about this, I'm just starting the  
conversation, being a bit of a devils advocate.  I would like to know  
if there is a way we can retain Lucene's solid stability and maturity  
and encourage new and better features and not have to maintain so much  
deprecated code.

I especially think this shorter cycle is useful when it comes to  
deprecated features (not that there is much difference between  
removing methods and adding methods.)  Basically, we have code in  
Lucene that we all agree should not be used, yet we leave it sitting  
in there for, on average 2 years or more.  Dropping that to be 1 year,  
on average, is not going to all of a sudden break everyone and make  
Lucene unstable.  Besides, if people like the deprecated methods so  
much, why upgrade in the first place?  No one is forcing them.   
Usually, the answer is there is some new feature somewhere else that  
is needed, but that just shows that people are willing to invest the  
time to get better features in the first place.  Besides, just because  
we can remove things, doesn't mean we have to remove them.  For  
instance, some bigger features that we improve, we may want to  
deprecate for more than one full release cycle.

Fieldable is, in my mind a prime example of needing the ability to  
announce additions.  Let's say we come up with some new-fangled Field  
type called Magic.  This thing is so beautiful we all wonder how we  
ever lived without it.  Great.  Now all we need to do is add an  
isMagic() declaration onto Fieldable and we're good.  Oops, can't do  
that.  Gotta wait 2 more years for 4.0.  Seriously, we have to be  
locked into an interface for 2 years or more?   And oh by the way, in  
that 2 years, Lucene has been left in the dust b/c every other open  
source search engine out there already has Magic capabilities.   
Furthermore, that gives us one 6 month window (+/-) to get it right  
for the next 2 years.  I know, it's a bit over the top, but I think it  
demonstrates the point.  I also don't see what is unstable about  
telling the community, well in advance, that the following API changes  
are coming, please plan accordingly.  Most projects out there don't  
even do that.  Seriously, in Maven you get updates to functionality  
without even knowing you are getting them and I am no where near  
advocating for that.

And again, I still think the more pertinent issue that needs to be  
addressed is how to better handle bugs in things like Tokenization,  
etc. where people may have dependencies on broken functionality, but  
haven't fully comprehended that they have such a dependency.  I don't  
think those fixes/deprecations should have to wait for a major release.

Does anyone have experience w/ how other open source projects deal  
with this?  Do they have explicit policies?  Is it ad hoc?  I know for  
instance, in a certain library I was using that the difference between  
what was announced as a beta and as 1.0 was quite different.  Granted,  
one could expect that a bit more out of something that was going from  
0.X to 1.0, but still it was a pretty significant, more or less  
unannounced change (unless you count following all the commit messages  
as announcement) and it will require a decent amount of work to upgrade.


-Grant


On Jan 17, 2008, at 6:58 PM, Steven A Rowe wrote:

> Hi Grant,
>
> On 01/17/2008 at 7:51 AM, Grant Ingersoll wrote:
>> Our minor release cycles are currently in the 3-6 months range
>> and our major release cycles are in the 1-1.5 year range.
>
> Since 2.0.0, including 2.3.0 - assuming it will be released in the  
> next week or so - the minor release intervals will have averaged  
> about 6.5 months, over three releases.
>
> Historically, the major release cycle intervals have roughly been:
>
>   1.0   - 6 months (March 2000 - October 2000)
>   2.0.0 - 6 years  (October 2000 - May 2006)
>
> Six years is an incredibly long time to maintain backward  
> compatibility.
>
> Assuming there will be a 2.4 release, and then 3.0 following it,  
> it's pretty optimistic (IMHO) to think that it will be released  
> before June 2008, so for 3.0, that would be:
>
>   3.0.0 - 2 years (May 2006 - May 2008)
>
> Two years doesn't seem so long in comparison :).
>
>> I think giving someone 4-8 (or whatever) months is more than
>> enough time to prepare for API changes.   I am not sure how
>> this would effect Index changes, but I do think we should
>> KEEP our current index reading policy where possible.  This
>> may mean that some deprecated items cannot be removed until
>> a major release and I think that is fine.
>
> Given the 6.5 month average minor release interval for the most  
> recent major release, and the relatively low probability that this  
> will shrink appreciably, you seem in essense to be advocating  
> altogether abandoning backward API compatibility from one (minor)  
> release to the next.
>
> However, below you are advocating a minimum of one "test balloon"  
> release between incompatible changes:
>
> On 01/17/2008 at 3:41 PM, Grant Ingersoll wrote:
>> [N]o interface/deprecation changes would be done without announcing  
>> it
>> and there being at least one release in the meantime.  Thus, if we
>> wanted to add isFancySchmancy() onto Fieldable today, it would have  
>> to
>> be announced, patch provided and referenced, a release without it  
>> (i.e.
>> 2.3) and then it would be available in 2.4.  By ad-hoc, I meant  
>> that we
>> wouldn't just announce it and then have it show up in 2.3 and not  
>> give
>> people time to digest it.
>
> If I understand you correctly, a major release series could contain  
> a whole series of non-aligned overlapping back-incompatible changes,  
> since you are allowing individual features to alter backward  
> incompatibility independently of other features.  I think this is  
> actually worse than just abandoning back-compatibility, since users  
> would have to look up information on each individual feature to be  
> able to figure out whether they can do a drop-in upgrade.
>
> Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>

--------------------------
Grant Ingersoll
http://lucene.grantingersoll.com
http://www.lucenebootcamp.com

Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ





---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message