lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <geobmx...@hotmail.com>
Subject RE: [Lucene.Net] Official stance on API changes between major versions
Date Fri, 02 Mar 2012 06:02:47 GMT

Andy, I appreciate your coppers.  Everyone is really quiet, It seems you want us to move forward,
I want us to move forward, Chris is actually holding back work becuase of this - lets go for
the breaking changes. ~P
 > Date: Thu, 1 Mar 2012 23:11:47 +0000
> From: andy.pook@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] Official stance on API changes between major versions
> 
> I am not a commiter but my company makes extensive use of Lucene.net. So
> here's my two pennies...
> 
> I understand that there is a commendable motivation to be gentle with api
> changes. Wanting to give plenty of warning by obsoleting methods.
> 
> Several points. First is that there is a change to the major version
> number. Users should expect changes to the api.
> Next, when this project was restarted last year the stated direction was to
> get caught up with the Java version and also to move towards a more dotnet
> style interface.
> 
> The discussions on the list do occasionally get bogged down in this kind of
> too and fro. A coach my sports team used once said something along these
> lines... "If the team can't choose then no one has made a convincing
> argument. So make a choice, any choice and just get on with it. If it turns
> out to be the wrong choice then at least you've learnt something."
> This is software. It's changeable.
> 
> My bias is that I want what's in V4 (codecs, NRT etc). I'm willing to take
> some pain if it means this project can accelerate.
> I would imagine that most serious uses of Lucene would be hidden within a
> service or at least isolated in some way, not dotted around all over the
> application. This is what isolation is for, to protect components from
> change. The impact of even fairly major api changes should be quite
> localised and refactorable. Intimidating, yes. More than a bit scary, of
> course. But worth it for getting the newer bits.
> By all means be professional, make proposals, have some discussion. But
> please let's not be too conservative, too timid.
> 
> 2.9.4g is a good release. We've been using it since shortly after it seemed
> stable. If there are users that need some stability then they should be
> advised to stick with g for a while.
> 
> Now that that is done and a hearty thank you for the work on both the code
> and the Apache process. My vote would be for some more radical changes to
> be allowed. Lets get through 3.0.3 and on to 3.5 and 4.0. Lets get to one
> of the original goals which is functional parity with Java and lets be bold
> with some of the dotnet modifications (note that being bold does not mean
> that one is reckless).
> 
> 
> I'm sure that some will say, yeah great sentiment, now send some patches. I
> agree. I have sent some very minor patches previously and it frustrates me
> that my company has not contributed more. We have just taken on a lot more
> people so I hope that we can be more active with Lucene.net soon.
> 
> --Andy
> 
> On 28 February 2012 18:17, Christopher Currens <currens.chris@gmail.com>wrote:
> 
> > I *really* don't mean to be a bother to anyone, but I'd like to continue
> > work on this.  I feel that until I can get a better sense of how the group
> > feels about this, I can't make much progress.  Perhaps this radio silence
> > is just because this email thread got lost in among the others.
> >
> > On Fri, Feb 24, 2012 at 6:50 PM, Prescott Nasser <geobmx540@hotmail.com
> > >wrote:
> >
> > > Im not against breaking compatibility when changing the version number to
> > > a new major 2 -> 3. Im not sure how others feel. Matching Java access
> > > modifiers seems like the right move.
> > >
> > > That said, what if we mark obsolete in 3.0.3 and when we make the jump to
> > > 4.0 wipe them out? In my head we shouldn't spend too much time cleaning
> > up
> > > 3.0.3 aside from bug fixes if were just going to swap it for 4.0 in the
> > > near future.
> > >
> > > There has to be a break at some point, making it with a major release is
> > > the best place to make it.
> > >
> > > Sent from my Windows Phone
> > > ________________________________
> > > From: Christopher Currens
> > > Sent: 2/24/2012 2:45 PM
> > > To: lucene-net-dev@lucene.apache.org
> > > Subject: [Lucene.Net] Official stance on API changes between major
> > versions
> > >
> > > A bit of background about what I've been doing lately on the project.
> > >  Because we've now confirmed that the .NET 3.0.3 branch is a completed
> > port
> > > of Java 3.0.3 version, I've been spending time trying to work on some of
> > > the bugs and improvements that are assigned to this version.  There
> > wasn't
> > > any real discussion about the actual features, I just created some (based
> > > on mailing list discussions) and assigned them to the 3.0.3 release.  The
> > > improvements I've been working on lately are ones that have bugged me
> > > specifically since I've started using Lucene.NET.
> > >
> > > I've worked on https://issues.apache.org/jira/browse/LUCENENET-468 and
> > > https://issues.apache.org/jira/browse/LUCENENET-470 so far.
> > >
> > > LUCENENET-740 is pretty much completed, all of the classes that
> > implemented
> > > Closeable() now implement IDisposable, having a public void Dispose()
> > > and/or protected virtual void Dispose(bool disposing), depending if the
> > > class is sealed or not.  What is left to do on that issue would be to
> > make
> > > sure that all of the tests are a) overriding the protected dispose method
> > > as needed and b) are actually calling Dispose or are in a using
> > statement.
> > >
> > > I've done quite a bit of work on LUCENENET-468, as well, though it is
> > going
> > > far slower than 470, because there's a lot more that needs to be done
> > and a
> > > bit more carefully, if I don't want to break anyone's code when they move
> > > to 3.0.  I'm not doing them in any particular order, I'm really just
> > > running VS2010 code analysis (Rule CA1024 only, actually) and changing
> > the
> > > ones suggested and ones I happen across to use Properties.  I've also
> > spent
> > > some time trying to wrap public fields in public properties.  However,
> > this
> > > one in particular has been posing some problems for me, and really brings
> > > me to the point of this email.
> > >
> > > Due to the way most class members are named (there's a lot of
> > redundancy),
> > > I'm finding it difficult to move forward with some of these refactoring
> > > without breaking backwards compatibility or adding more things to change
> > in
> > > regards to LUCENE-446 and CLS compliance.  For classes that are
> > > specifically marked internal, this of course, hasn't been a problem, I
> > just
> > > make the breaking change and fix it other places in the library.  This
> > is,
> > > of course, a problem with class that are public, including classes that
> > > *should not* be marked public but are anyway.  It's a little off topic,
> > but
> > > we stray far sometimes from the access modifiers defined on the java
> > > classes.  I've found that nearly all cases were because they were needed
> > > for the NUnit tests.  That problem no longer exists in 3.0.3, as the Test
> > > library can now access those types in the core assembly.  I personally
> > feel
> > > that whenever we find an difference in access modifiers, we change it to
> > > match java, however, if customers are using that, well, now they can't.
> > >  That's issue number one that I wanted to discuss with the group.
> > >
> > > Going back to the difficulties in ".NET-ifying" the API, often times if I
> > > want to convert a Get[name]()/Set[name]() group or individual method to a
> > > property, the resulting property name will conflict with an already
> > > existing public field, another method with the exact same name, or the
> > name
> > > of the enclosing type itself.  The latter can't easily be solved, so I'm
> > > not fretting too much about it.  The first two are easier to solve, but
> > not
> > > without breaking backwards compatibility for some users.
> > >
> > > Now, the API between 2.x and 3.x differs greatly, so some customers *may*
> > > have to make changes anyway.  However, that's not a good rule, since
> > most,
> > > if not all, of the breaking changes made to Lucene.NET were first
> > obsoleted
> > > for a period of time, and thus they were given plenty of warning to
> > change
> > > their code.  Unfortunately, with these changes, we haven't given them the
> > > same notice.  So far, I've been trying my best to make sure that all
> > > changes that have been made, have been done in a way that won't break any
> > > compatibility.  All of the classes that now implement Dispose() still
> > have
> > > a Close() method that's now obsoleted (see the PS).  For properties, I've
> > > been keeping the Get/Set methods, moving the code to the property, and
> > > marking them obsoleted.  I figure that this is the workflow we want, but
> > > I'm finding it's not always possible, so I'd like to see what the group
> > has
> > > to say about it.  How strict will we be?
> > >
> > >
> > > Thanks,
> > > Christopher
> > >
> > > P.S. So in regards to classes implementing Dispose() and backwards
> > > compatibility.  Yes, they still have a Close() method that is obsoleted.
> > >  However, with some classes, for me to make the change, I had to add
> > > IDisposable to an abstract class or interface.  In some cases, it was
> > > breaking.  If Close() before was abstract, I made the new protected void
> > > Dispose(bool) method abstract, removed virtual from Close() and had it
> > call
> > > Dispose().  This is a breaking change since and class that inherited from
> > > that class will now have multiple build errors, one for trying to
> > override
> > > a non-virtual member (Close()) and another for not implementing the
> > > protected dispose method.  So, perhaps that needs to be discussed as
> > well.
> > >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message