Replacing a nightly build

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing a nightly build

jrodenburg
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.
Reply | Threaded
Open this post in threaded view
|

Re: Replacing a nightly build

Yonik Seeley-2
On 11/7/06, Jeff Rodenburg <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Replacing a nightly build

Chris Hostetter-3

: 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

Reply | Threaded
Open this post in threaded view
|

Re: Replacing a nightly build

Yonik Seeley-2
On 11/7/06, Chris Hostetter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Replacing a nightly build

sangraal
That would be helpful, as long as it's conveyed clearly.

-S

On 11/7/06, Yonik Seeley <[hidden email]> wrote:

>
> On 11/7/06, Chris Hostetter <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Replacing a nightly build

Chris Hostetter-3
In reply to this post by Yonik Seeley-2

: 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

Reply | Threaded
Open this post in threaded view
|

Re: Replacing a nightly build

Bill Au
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 <[hidden email]> wrote:

>
>
> : 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
>
>