关于将Lucene从2.2升级到2.9再到3.1的问题

我有一个使用Lucene 2.2.x的现有软件，我需要升级到3.1。要进行此升级，我已阅读了建议先升级到 2.9.x 的文档，删除所有弃用警告，然后升级到 3.1.x。我已经部署了现有的索引，我需要保持代码兼容。

我的主要问题来自处理日期。在2.2.x中，我不得不使用DateTools.dateToString（）将Date.getTime（）转换为可以索引和存储的字符串。我在每个文档上创建了两个字段。一个用于搜索，以小时分辨率存储，另一个字段未分析。现在Lucene 2.9.x支持字符串以外的其他数据类型。如果这些新类型与使用 DateTools 将日期转换为字符串的先前版本相对应，是否可以在 RangeQueries 中使用？以下是我也更改了它的代码：

以前：

return new RangeFilter("dateArchived-stored",
                DateTools.dateToString(start, DateTools.Resolution.MILLISECOND),
                DateTools.dateToString(end, DateTools.Resolution.MILLISECOND),
                false, true );

后：

return NumericRangeFilter.newLongRange("dateArchived-stored", 
                                       start.getTime(), 
                                       end.getTime(), true, true );

既然 Lucene 支持非字符串数据类型，我们是否需要像使用 Term 查询那样关注日期的解析？

IndexWriter 需要声明一个 MaxFieldLimit。以前的版本没有。使用 UNLIMITED 的行为是否与先前版本的行为相同？鉴于我将阅读的索引是使用2.2创建的，因此使用UNLIMITED是最安全的吗？

以前：

new IndexWriter( indexDirectory, analyzer )

后：

new IndexWriter( FSDirectory.open(indexDirectory), analyzer, true, IndexWriter.MaxFieldLength.UNLIMITED )

排序对象需要 SortField 声明，该声明需要该字段的类型。对于使用 2.2.x 版本编制索引的现有字段，我们是否可以将以前索引为 String 的字段声明为另一种类型的字段，或者它们应始终为 SortField.STRING？

以前：

new Sort("timestamp", false )

后：

new Sort(new SortField("timestamp", SortField.LONG, false) )

这是否适用于在 2.2.x 中构建但由 2.9.x 读取的索引？

最后，使用2.2.x内置的索引直接进入3.1.x会有什么问题吗？我将在我的本地开发系统上过渡到2.9.x，但在现场，它将从2.2.x直接过渡到3.1.x。我是否必须发布使用 2.9.x 的版本？