Marvin Humphrey wrote on 7/18/10 12:59 PM: > > I propose a minimalist strategy that will allow us to get to a release as > quickly as possible: > > 1. Branch Lucy off the last KS bugfix release rather than svn trunk. > 2. Perform IP clearance and relicensing. > 3. Perform a few massive find and replace operations to change the imported > codebase to "Lucy". > 4. Add code to enable Lucy to read existing KinoSearch 0.3x indexes. > 5. Consider moving a few classes around. > 6. Write a Lucy::Docs::KinoSearch2Lucy transition guide and a > "kinosearch2lucy.pl" tool to adapt user codebases using 0.3x > automatically. >
+! to all those. > > It probably makes sense to make one more KinoSearch release addressing some of > the issues for the transition. In particular, in svn trunk, FullTextType and > StringType have been consolidated into TextType. It would be nice if new Lucy > users never had to think about distinguishing between FullTextType and > StringType, since they're going away anyway. > > I think we draw the line at moving classes around, though. Yes. I'd like to see a stable KinoSearch3 release with the least amount of changes possible from the current stable branch. > There are a number > of other issues that need to be addressed before we fork off a stable "Lucy1" > branch. [snip] > I think if we market the initial Lucy release as "help us get to a stable > release", then A) people will be more forgiving of our "work in progress", and > B) we may attract more contributors. We can put off the more disruptive work > until later. > > Sound like a plan? those all sound good for Lucy. Should not impede the KS3 release though. I imagine Lucy1 as an improvement on KS3, inspiring users to migrate. -- Peter Karman . http://peknet.com/ . [email protected]
