I agree that's a risk... but this being open source, I think it'd balance out?
So eg right now I'm looking @ speeding up PhraseQuery (thanks to Robert's prodding ;) ). These changes are all under the hood, so, I would do this on the stable branch. There's no reason not to. There are also good incentives to do something on stable branch, eg, the feature will see the light of day sooner than it will on experimental. For people working on features that their "sponsors" really need, doing so on the stable branch means they are available in a real release sooner. And by having a "safe" place for experimental stuff to land, we save the risk of destabilizing the stable branch, that we face today. And we would no longer need to go to herculean efforts (like Uwe's back compat layer for analysis). Flex would've finished much sooner too :) Mike On Fri, Apr 16, 2010 at 12:12 PM, Mark Miller <markrmil...@gmail.com> wrote: > I'd be for this plan if I really thought the stable branch would get similar > attention to the experimental branch - but I have some doubts about that. > Its a fairly small dev community in comparison to other projects that do > this ... > > Dev on the experimental latest greatest fun branch, or the more in the past, > back compat hassle stable branch? Port most patches to two somewhat > diverging code bases? > > If that was actually how things worked out, I'd be +1. I just wonder ... > with the right framing I do think its possible though. > > > On 04/16/2010 11:45 AM, Michael McCandless wrote: >> >> Getting back to the stable/experimental branches... >> >> I think, with separate stable& experimental branches, development >> would/should be active on both branches. It'd depend on the >> feature... >> >> Eg today we'd have 3.x stable branch and the experimental branch >> (= trunk). >> >> Small features, bug fixes, would be ported to both branches. I think >> features that deprecate some APIs would still be fine on the stable >> branch. Major changes (eg flex) would only be done on the >> experimental branch. >> >> This empowers us on a feature by feature case to decide whether it'll >> be in the stable release or not. The stable branch releases would >> be 3.0, 3.1, etc., but we could still do the .Z releases (3.0.1, >> 3.0.2) for bug fixes, if we need to. >> >> And we could do alpha releases off the experimental branch as we think >> we're getting close to cutting a new stable release (4.0). >> >> Mike >> >> On Thu, Apr 15, 2010 at 6:58 PM, Robert Muir<rcm...@gmail.com> wrote: >> >>> >>> On Thu, Apr 15, 2010 at 6:50 PM, DM Smith<dmsmith...@gmail.com> wrote: >>> >>>> >>>> Robert has already started one. (1488 I think). >>>> >>> >>> and it could work with this new scheme... because then you could use an >>> older icu jar file with an older lucene-analyzer-icu.jar or whatever and >>> you >>> have it more under control. >>> under the "existing scheme" you cant really improve back compat with ICU, >>> because they make API changes and backwards breaks and such themselves, >>> so >>> you cant make one "Tokenizer" say that does anything meaningful that >>> works >>> with all versions of it... >>> but it would be cool to say: here is lucene-analyzer-icu-4.0.jar that >>> works >>> with icu 4.4. and you could keep using that as long as you have to >>> (meanwhile trunk could start using icu 4.6) >>> >>> -- >>> Robert Muir >>> rcm...@gmail.com >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> > > > -- > - Mark > > http://www.lucidimagination.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
