lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Pook <>
Subject Re: [Lucene.Net] Official stance on API changes between major versions
Date Thu, 01 Mar 2012 23:11:47 GMT
I am not a commiter but my company makes extensive use of 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 soon.


On 28 February 2012 18:17, Christopher Currens <>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 <
> >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:
> > 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 and
> > 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.
> >

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