+1 The code has changed so radically between Solr1.2 and Solr1.3 .Because 1.3 is not released most of us have to stick to 1.2 . So anything that we build must work on 1.2 and if I wish to contribute back to Solr it has to be 1.3 compatible. SOLR-469 is a good example where I had to really hack my code hard to ensure that I contained the version specific dependencies to one file .
This is a good starting point . Let us get the list of issues which can be easily fixed and apply the patches and push out a release . --Noble On Tue, May 20, 2008 at 2:23 PM, Andrew Savory <[EMAIL PROTECTED]> wrote: > Hi, > > (discussion moved from -user to -dev) > > 2008/5/19 Chris Hostetter <[EMAIL PROTECTED]>: > >> If people are particularly eager to see a 1.3 release, the best thing to >> do is subscribe to solr-dev and start a dialog there about what issues >> people thing are "show stopers" for 1.3 and what assistance the various >> people working on those issues can use. > > So, what are the show stoppers, how can we help, what can we reassign > to a future release? > > Taking a look through the list there's quite a few issues with patches > attached that aren't applied yet. Clearing these out would cut the > open bug count by almost half: > > SOLR-515 > SOLR-438 > SOLR-351 (applied?) > SOLR-281 (applied?) > SOLR-424 > SOLR-243 (stuck in review hell?) > SOLR-433 > SOLR-510 > SOLR-139 > SOLR-521 (applied, waiting to be closed) > SOLR-284 > SOLR-560 > SOLR-469 > SOLR-572 > SOLR-565 > > It's a little weird to see patch 'development' going on in JIRA > (sometimes for over a year), rather than getting the patches into svn > and then working there... I'd worry that some valuable code history is > getting lost along the way? Yes, it's a tough call between adding > 'bad' code and waiting for the perfect patch, but bad code creates > healthy communities and is better than no code :-) > > > Andrew. > -- > [EMAIL PROTECTED] / [EMAIL PROTECTED] > http://www.andrewsavory.com/ > -- --Noble Paul
