lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gopikrishnan Subramani <gopi.subram...@gmail.com>
Subject Re: Proposal for changing Lucene's backwards-compatibility policy
Date Fri, 30 Oct 2009 10:54:02 GMT
My vote is for option A. It's generally implied that a major version brings
in major changes (api as well as others), while the minor is, well, minor.
Why should that be broken for lucene? It would become increasingly difficult
for the lucene user community to catch up if they skipped one or two minors,
if that rule is broken.

-Gopi
On Wed, Oct 28, 2009 at 6:44 AM, Yonik Seeley <yonik@lucidimagination.com>wrote:

> On Tue, Oct 27, 2009 at 9:07 PM, Luis Alves <lafadev@gmail.com> wrote:
> > But there needs to be some forced push for these shorter major release
> > cycles,
> > to allow for code clean cycles to also be sorter.
>
> Maybe... or maybe not.
> There's also value in a more stable API over a longer period of time.
> Different people will pick a different balance, and it's not as simple
> as declaring that we need to be able to remove older APIs faster.
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message