It makes sense to me, but it also means that 4.0 will go out with deprecated API that will exist until 5.0 is out.
I only raised it to learn if this was done by mistake, or there is some logic behind it. I guess that for me, reading MIGRATE will be enough, but I cannot speak for others. I don't mind if they are left. Shai On Wed, Feb 15, 2012 at 1:33 PM, Robert Muir <rcm...@gmail.com> wrote: > Hi Shai, > > I think in some cases its good for us to add deprecated APIs to trunk > rather than completely breaking users. > > We can look at these as 'migration paths' for the user... > > Here is a good example of one i specifically requested (Mike > implemented, thanks!): > https://issues.apache.org/jira/browse/LUCENE-3682 > > In 4.0 we totally changed the Document/Field API (FieldType etc), but > rather than forcing ALL users to change ALL their code and learn the > new API, i think its very helpful if, at least for a while, we support > something that looks like the "old" api with Field.STORE, etc, etc. > > For a huge amount of apps, this might help them > experiment/test/migrate to Lucene 4.0 without being frustrated. > > In general I think if we can add transition mechanisms like this to > make it easier for people to cut over, we should.... are there reasons > we should not do this? > > On Wed, Feb 15, 2012 at 1:59 AM, Shai Erera <ser...@gmail.com> wrote: > > Hi > > > > Why do we have deprecated methods on trunk (e.g. IndexReader.open())? > > Shouldn't they be deleted? > > > > Shai > > > > -- > lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
