Replacing a nightly build
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 maintaining the code stack under deployment? thanks.
Re: Replacing a nightly build
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 restarting, are there any steps that everyone is following in maintaining the code stack under deployment? That should be fine as there haven't been any incompatible changes to the index format, or to the request or response formats (at least to anything that had a few weeks to stabilize). IMO, one should re-test the complete application with the new Solr version if the index or search service is important. We should try and make it clear when something does change. There are patches in the works that will change the response format: http://issues.apache.org/jira/browse/SOLR-59 If you are sensitive to response format changes, one think you can do is make sure and specify a version number in your query requests. -Yonik
Re: Replacing a nightly build
: 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 since we started the nightly builds. but in general 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. -Hoss
Re: Replacing a nightly build
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 highlight backward incompatible changes somehow (a separate section in CHANGES.txt, or an all caps keyword that stands out). -Yonik
Re: Replacing a nightly build
: 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 the it in the bug fix or new features section, but also call it out in a new section for easy refrence) -Hoss
