lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: [jira] Updated: (SOLR-1067) QueryParsing.parseFunction uses Singleton Core (SolrCore.getSolrCore())
Date Tue, 18 Aug 2009 22:55:22 GMT

: > : I think we've done everything reasonable for 1.4, moving the rest to 1.5
: >
: > from a project management / CHANGES.txt clrity stanpoint, it seems like we
: > should be creating new issues for any parts of issues like this one that
: > we're pushing off post 1.4 ... otherwise 1.4's CHANGES.txt has a list of
: > bugs that were fixed, but when you look up the bug details it says it's
: > still open.  and down the road 1.X will say it fixed hte exact same but.
: 
: I guess this is something I'd avoid adding to CHANGES.txt all together
: - it's really pretty internal stuff.

That's a slippery slope dude ... even if something is in the internals it 
can have behavioral effects on people who don't touch it directly (not to 
mention plugin developers who might actually be touching it directly)

I think just about everything should be in CHANGES.txt ... if someone 
upgrades and gets a weird bug, the first place (we want people) to look 
for explanations is CHANGES.txt ... in an ideal world it lets people post 
questions like "when i upgraded from 1.3 to 1.4 i started getting errors 
with XYZ, i noticed CHANGES.txt mentions ABC and it occured to me that i 
use XYZ w/ABC so maybe that's causing this bug?"

leaving stuff out of CHANGES just because it's an internal change seems 
like it just makes everybodies life harder when bugs pop up.


-Hoss

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message