lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <mhern...@o19s.com>
Subject Re: Proposal Stage: Backwards Compatibility / Support
Date Sun, 02 Jan 2011 22:03:06 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message