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 restarting, are there any steps that
everyone is following in ma
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
: 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, 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
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
: 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
