Andrew Lippert wrote: > Strange sequence of circumstances in this one. I typically lock in on > a version string in my environment after getting everything running in > production to prevent any future updates from inadvertently breaking > something. In this case, this was the first trip to production with > Thinking Sphinx. It just so happens that the conversion from Ferret to > Sphinx started a couple weeks ago and my dev system wound up with > 1.1.24. Pat released 1.2 last Saturday just before I started the > Production server configuration and I didn't notice the change in > version number between dev and prod. If I'd have started on the prior > Friday as opposed to this Monday I never would have hit this storm. My > bad. I completely agree with you on version settings in environment > and have got that locked in now that everything is working!
Interesting approach. While true that the specific timing wasn't in your favour, locking TS to the version you used in dev/tests would've removed timing as a risk factor all together. You would've had a slightly out-of-date version of TS in production, but at least you know it's likely to work! :) What's the motivation behind only locking gem versions once you've confirmed everything works in production? -- James Healy <jimmy-at-deefa-dot-com> Sat, 01 Aug 2009 02:29:26 +1000 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en -~----------~----~----~----~------~----~------~--~---
