I second having a separate redundent section. It makes it easier to find
them when there is a single place to look for them.
Bill
On 11/7/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: I'm just wondering if we might need to highlight backward incompatible
: changes somehow (a separate sect
: I'm just wondering if we might need to highlight backward incompatible
: changes somehow (a separate section in CHANGES.txt, or an all caps
: keyword that stands out).
a seperate section where we (redundently) put info about backward
incompatible chagnes is probably a good idea (ie: still put t
That would be helpful, as long as it's conveyed clearly.
-S
On 11/7/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 11/7/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> comparing the CHANGES.txt files of any two nightly builds is the best
way
> to see what thigns have changed that you might wn
On 11/7/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
comparing the CHANGES.txt files of any two nightly builds is the best way
to see what thigns have changed that you might wnat to test before
deploying the nw version to a "production" environment.
I'm just wondering if we might need to high
: We should try and make it clear when something does change. There
: are patches in the works that will change the response format:
I think we've done a pretty good job of anouncing "major" things on
solr-user ... especially since I don't think we've had any non-backwards
compatible changes si
On 11/7/06, Jeff Rodenburg <[EMAIL PROTECTED]> wrote:
What is the recommended path to deployment for replacing a solr nightly
build with another? In our scenario, we're updating our current build is
roughly 3 months old. We're updating to the latest.
Aside from replacing the bits and restartin
