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<geobmx...@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: digyd...@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:thowar...@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<pierogi...@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: mhern...@amptools.net [mailto:mhern...@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
