lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <ryan...@gmail.com>
Subject Re: Solr 1.4
Date Fri, 15 May 2009 02:36:03 GMT
As a general rule any feature/API from 1.3 that you are using in 1.4  
should work on /trunk -- any chances to this are always in CHANGES.txt

The place were you get in to murky water is with new features/API  
since the previous release -- in this case, you will need to follow  
the JIRA issues to have a sense of how "stable" the specific feature is.


On May 14, 2009, at 5:25 PM, Eger, Patrick wrote:

> 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:gsingers@apache.org]
>> Sent: Thursday, May 14, 2009 11:33 AM
>> To: solr-dev@lucene.apache.org
>> 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: noble.paul@gmail.com [mailto:noble.paul@gmail.com] On Behalf
> Of
>>>> Noble Paul ??????? ??????
>>>> Sent: Thursday, May 14, 2009 5:55 AM
>>>> To: solr-dev@lucene.apache.org
>>>> 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
>>>> <gsingers@apache.org>
>>>> 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 ;-)
>>>>>
>>>>>


Mime
View raw message