lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Thompson <pierogi...@hotmail.com>
Subject RE: [Lucene.Net] Official stance on API changes between major versions
Date Sat, 03 Mar 2012 23:11:18 GMT
Jumping back into this debate... I still feel that automated porting is the
fastest way to get up to date and stay up to date.

So to that effect I finally got rolling on a fork of Sharpen which I have
made public here:
https://github.com/pierogitus/Grindstone

I've been using java Lucene 3.5 as my test port with the initial goal of
producing an output that will build in VS with no pre/post processing. I've
fixed several issues so far and have gotten to the point where the
conversion will finish without errors and I think VS shows the actual number
of C# errors (instead of just stopping because there are too many errors).

I've found it pretty straightforward to fix issues in the Sharpen code even
though this is pretty much the most java I've ever done. So take a look at
what I've done and see if you can contribute.

Alex 

-----Original Message-----
From: Prescott Nasser [mailto:geobmx540@hotmail.com] 
Sent: Thursday, March 01, 2012 10:03 PM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] Official stance on API changes between major
versions


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
View raw message