Fair enough, any yes we would definitely do extensive testing before any release. I think the problem is, that without any "official blessing" I as a user have no real way of knowing the current state of TRUNK. IE is some feature in the middle of a rework? Is there some kind of janky partially-solved issue that is "known"? Questions like that make it difficult for me to know where to spend my (limited) testing time, so in the end I really end up not doing it at all. I'd likely be able to commit to RC X testing or monthly blessed snapshot kind of thing though, which is why I mention it. Only speaking for myself but I surmise others might be in the same boat. Again though, thanks for the great product!
Best Regards, Patrick > -----Original Message----- > From: Grant Ingersoll [mailto:[email protected]] > Sent: Thursday, May 14, 2009 11:33 AM > To: [email protected] > Subject: Re: Solr 1.4 > > I'm not suggesting you don't validate it first with your own tests. I > can't imagine you take a release and just deploy it in production, > right? > > I'm just observing that if everyone (besides the committers) takes > this "release only" approach, then you quickly realize that the large > majority of testing in real production systems happens _after_ > release, not before, which makes it seem less like a "release" and > more like a "release to QA". We committers and contributors make best > efforts to test, but the community is responsible for finding most > issues simply (b/c of sheer volume) regardless of what name you want > to apply to the actual bits they are testing (i.e. nightly/release/ > Giant Ball of Solr Fun). In other words, if you are planning on > upgrading to 1.4, then you should be trying out 1.4-dev in your test > environment before release, not after. > > Just my two cents, > Grant > > > On May 14, 2009, at 12:35 PM, Eger, Patrick wrote: > > > Yeah, at least for us, the corporate overlords (and our operations > > team) would be *extremely* hesitant to go to production with any > > kind of snapshot release. If there was a "weekly stable" or similar > > that might be slightly better, but definitely not a CI/nightly. > > > > > > Best Regards, > > > > Patrick > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of > >> Noble Paul ??????? ?????? > >> Sent: Thursday, May 14, 2009 5:55 AM > >> To: [email protected] > >> Subject: Re: Solr 1.4 > >> > >> The advantage is that there is strength in numbers. There will be a > >> lot of users using the release build and if there is an issue the > >> user > >> can rest assured that there will others who need the same fix on the > >> same revision. (so a better chance of a resolution) > >> > >> moreover there won't be any half baked fixes in a release > >> > >> > >> > >> On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll > >> <[email protected]> > >> wrote: > >>> > >>> On May 13, 2009, at 7:04 PM, Eger, Patrick wrote: > >>> > >>>> +2 > >>>> > >>>> This would be very much appreciated by your users, I at least was > >>>> expecting March :-) We were hoping to release with 1.4 > >>>> (specifically > >> for > >>>> java replication and field collapsing) but had to redo some plans > >>>> since > >>>> it seemed to keep slipping. > >>> > >>> It's not like anything all that magical necessarily happens with a > >> release. > >>> Sure, we package up the bits and there is some legal > >>> ramifications, I > >>> suppose, but the software is more or less the same. In other words, > >> most > >>> people should be fine with trunk, or some recent revision. In fact > >>> if > >> more > >>> people tried out trunk, it would be faster to release b/c we would > >>> have > >> more > >>> vetting done. > >>> > >>>> Not complaining, just FYI on our experiences > >>>> (it's a free product after all). A 4-6 month release schedule > >>>> would be > >>>> ideal for us, whereas it looks like it'll be ~9-10 months > >>>> currently? > >>>> Again, not complaining, just trying to get SOLR into production! > >>> > >>> http://wiki.apache.org/solr/HowToContribute ;-) > >>> > >>>
