lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Jordan <robe...@gmx.net>
Subject Re: Proposal Stage: Backwards Compatibility / Support
Date Mon, 03 Jan 2011 13:52:48 GMT
On 02.01.2011 23:03, Michael Herndon 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?

I will take care of the Mono support.

Robert


>
>
> 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
>>>>
>>>>
>>>
>>
>>
>
>
>



Mime
View raw message