lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <thowar...@gmail.com>
Subject Re: Proposal Stage: Backwards Compatibility / Support
Date Sun, 02 Jan 2011 23:28:09 GMT
For bug fix releases that need to come after a main release but can't
increment the version number, then a build number is ok, but generally
I prefer to just refer to them by name and revision number.

eg:

build 3.0.0.234 = 3.0.0 RTM (rev 100)
build 3.0.0.446 = 3.0.0 HotFix1 (rev 123)

etc...

This is because build numbers can be rather arbitrary, and doesn't
help much when you're working with the library from code and not
binaries. Knowing what SVN revision a given release is, is more
useful.

Regarding skipping the intermediate Java releases... The only benefit
to matching each of those is if someone were to need to port a Java
application that relied on an intermediate version to C#, and didn't
want to do the work of upgrading to a newer version (assuming a lack
of backward compatibility for their use case). Then they would need an
exact matching version in C#.

This seems like an unlikely use case, and it's my opinion we should
just skip the intermediate releases and make our next release after
2.9.2 match the latest Java releases (eg. 2.9.4 and 3.0.3).

While there's a sense of urgency about getting a 3.X release out for
.NET, I think the community would be better served by getting the
2.9.4 release out. This is following the "bug fixes before features"
principle for scheduling releases. Our user base is currently using
2.9.2. I think we'd serve them better by first giving them a 2.9.4
build that fixes bugs with the current code without introducing any
breaking API changes.

Also, if we're developing a new conversion process for 3.X and beyond,
we'll need time to develop that correctly. It's not a trivial task.
Applying bug fixes from 2.9.2 to 2.9.4 shoudl be much easier and could
probably be done manually.

Regarding Mono support... I think we should. I don't know how much
that entails at this point. I know there's an open JIRA ticket for
this at:
https://issues.apache.org/jira/browse/LUCENENET-361

Supporting Mono could be as easy as applying that patch.

I'd also like to address:

https://issues.apache.org/jira/browse/LUCENENET-167

And make a build that can run on the compact framework. I'm not sure
Silverlight support is so important, but Compact Framework support
would be a big win, IMO.

Thanks,
Troy






On Sun, Jan 2, 2011 at 2:03 PM, Michael Herndon <mherndon@o19s.com> wrote:
> The complicated part about having a release for release is that there might
> be certain bugs that are only on our side, thus paying attention to the
> build interval becomes important for people.
>
> i.e.
>
> build 3.0.0.234 = 3.0.0 release
> build 3.0.0.446 = 3.0.0 hotfix
>
> Is there a better way of handling or noting these type of releases?
>
> Is there any benefit of doing all of 3.0.x & 2.9.x releases versus starting
> with the latest of each branch and moving forward from there?
>
> Also are we going to ensure mono support?
>
>
> On Sun, Jan 2, 2011 at 4:36 PM, Prescott Nasser <geobmx540@hotmail.com>wrote:
>
>>
>> Also, was there any pre/post processing involved in these files? Was it
>> manual / scripts etc? Just trying to get a feel for the work involved.
>>
>>
>> > From: digydigy@gmail.com
>> > To: lucene-net-dev@lucene.apache.org
>> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
>> > Date: Sun, 2 Jan 2011 19:03:25 +0200
>> >
>> > > The 3.0.X ports should be 100% Sharpen
>> > Why?
>> > What about other alternatives?
>> >
>> > Lucene.java 3.0.3 ==> .Net Conversion Samples (
>> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
>> >
>> > DIGY
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Troy Howard [mailto:thoward37@gmail.com]
>> > Sent: Saturday, January 01, 2011 1:58 AM
>> > To: lucene-net-dev@lucene.apache.org
>> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
>> >
>> > We are inheriting the outstanding issues facing the Lucene.Net project.
>> >
>> > This includes remaining committed to providing a line-by-line port
>> > that stays in sync with the Java Lucene releases.
>> >
>> > The project is currently extremely behind schedule on this. The 2.9.2
>> > code base, which is widely used and thus a fairly well received build,
>> > has never been formally packaged as a release (i.e. binary builds,
>> > etc). This is the first order of business to take care of (in terms of
>> > code).
>> >
>> > After that we need to evaluate weather or not to create releases to
>> > match all subsequent releases made by the Java Lucene project.
>> >
>> > Those releases are:
>> > - 3.0.0
>> > - 3.0.1
>> > - 2.9.3
>> > - 3.0.2
>> > - 2.9.4
>> > - 3.0.3
>> >
>> > In the interest of time, we could skip some of the intermediate
>> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
>> >
>> > The 3.0.X ports should be 100% Sharpen conversions and post-processing
>> > scripts. Once written, anyone should be able to repeat the process of
>> > pulling down the appropriate Java Lucene SVN revision, executing the
>> > porting scripts, and building the resulting .NET code, yield a valid
>> > 3.0.X release with a 1:1 matching API.
>> >
>> > This is something we will need to continue being able to do for every
>> > subsequent Java Lucene release.
>> >
>> > This aspect of our development should be completely separate from our
>> > refactoring/re-imagining of a more .NET-like API. They need to be
>> > separate development branches, and possibly even completely different
>> > implementations. We will attempt to reuse as much of the automated
>> > port code as we can, with the understanding that the goal of the
>> > secondary branch is to make a high-quality .NET implementation of
>> > Lucene, rather than a API compatible implementation.
>> >
>> > Thanks,
>> > Troy
>> >
>> >
>> >
>> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <pierogitus@hotmail.com>
>> wrote:
>> > > Maybe we could just bug-fix support the current 2.9.2 codebase unless
>> people
>> > > really need something in 2.9.x
>> > >
>> > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
>> > > version.
>> > >
>> > > I'd like to throw another idea into the mix which is perhaps the
>> idiomatic
>> > > version could be created by an automated refactoring of the
>> line-by-line. It
>> > > might be additional upfront work but might make it easier for future
>> changes
>> > > from java lucene to be propagated down.
>> > >
>> > > Alex
>> > >
>> > > -----Original Message-----
>> > > From: mherndon@amptools.net [mailto:mherndon@amptools.net] On Behalf
>> Of
>> > > Michael Herndon
>> > > Sent: Friday, December 31, 2010 1:28 PM
>> > > To: lucene-net-dev@lucene.apache.org
>> > > Subject: Proposal Stage: Backwards Compatibility / Support
>> > >
>> > > *Backwards Compatibility / Support: *
>> > > This is definitely something we need to cover.
>> > >
>> > > I'm guessing the obvious choice would be to continue the 2.9.X versions
>> > > under sharpen, maintain the current api thats has java idioms so that
>> people
>> > > can continue to use it, release patches, ensure stability with the
>> current
>> > > community. This would be important for people who have built products
>> on top
>> > > of lucene.net.
>> > >
>> > > The 3.0 version should probably match java in terms of breaking the api
>> due
>> > > to the language changes or maybe even a separate project inside:
>> > > lucene.netredux (for lack of a better term at the moment).
>> > >
>> > >
>> > > *
>> > > *
>> > > --
>> > > Michael Herndon
>> > >
>> > >
>> >
>>
>>
>
>
>
> --
> Michael Herndon
> Senior Developer (mherndon@o19s.com)
> 804.767.0083
>
> [connect online]
> http://www.opensourceconnections.com
> http://www.amptools.net
> http://www.linkedin.com/pub/michael-herndon/4/893/23
> http://www.facebook.com/amptools.net
> http://www.twitter.com/amptools-net
>

Mime
View raw message