One more addition:
 - Consider a different wiki... our current style will serve us poorly
across major version bumps esp.  We need versioning.   A different
option could include moving more documentation onto the website, where
it would be versioned.  Getting something easy to edit/change would be
the key there.... we don't have that currently.

-Yonik


On Tue, Mar 16, 2010 at 10:06 AM, Yonik Seeley <yo...@apache.org> wrote:
> another minor addition:
>  - move to Junti4 for new tests... and some old tests might be
> migrated (for speed issues)
>
> I already have a SolrTestCaseJ4 that extends LuceneTestCase4J that
> avoids spinning up a solr core for each test method... but I need to
> be able to reference  LuceneTestCase4J from the lucene sources (i.e it
> works in the IDE, but not on the command line right now).
>
> -Yonik
>
>
>
>
> On Tue, Mar 16, 2010 at 10:00 AM, Yonik Seeley <yo...@apache.org> wrote:
>> Here is a very rough list of what makes sense to me:
>> - since lucene is on a new major version, the next solr release
>> containing that sould have a new major version number
>>  - this does not preclude further releases on 1.x
>>  - for simplicity, and the "single dev" model, we should just sync
>> with lucene's... i.e. the next major Solr version would be 3.1
>> - branches/solr would become the new trunk, with a shared trunk with
>> lucene in some structure (see other thread)
>> - solr cloud branch gets merged in
>> - we move to Java6 (Java5 has already been EOLd by Sun unless you pay
>> money... and we need Java6 for zookeeper, scripting)
>> - remove deprecations (finally!), and perhaps some additional cleanups
>> that we've wanted to do
>>
>> -Yonik
>>
>

Reply via email to