lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anshum Gupta <ans...@anshumgupta.net>
Subject Re: [VOTE] Release Lucene/Solr 5.3.2-RC1
Date Fri, 15 Jan 2016 11:44:30 GMT
Thanks Adrien and every one else.

The vote has passed. I am traveling back to San Francisco (14 hours away)
so I will resume the release process as soon as I'm back.


On Thu, Jan 14, 2016 at 5:32 PM, Adrien Grand <jpountz@gmail.com> wrote:

> +1 SUCCESS! [1:11:11.509082]
>
> I also tried to run TestBackwardsCompatibility from the 5.4 branch on an
> index generated by this release candidate, this did not catch problems.
>
> Le mer. 13 janv. 2016 à 09:09, Adrien Grand <jpountz@gmail.com> a écrit :
>
>> Le mer. 13 janv. 2016 à 07:19, Ryan Ernst <ryan@iernst.net> a écrit :
>>
>>> While this isn't something we have tests for in
>>> TestBackwardsCompatibility (that only tests every previous version against
>>> the current version), we do have tests in TestVersion for parsing versions
>>> that do not have constants (see testForwardsCompatibility). Version
>>> constants are only shortcuts to Version objects with known values, not what
>>> are passed around.
>>>
>>
>> Thanks Ryan. So the version part should be fine at least.
>>
>> On Wed, Jan 13, 2016 at 2:31 AM, Yonik Seeley <yseeley@gmail.com> wrote:
>>>>
>>> Seems like this versioning limitation should be fixed - we should
>>>>> always be free to create bugfix releases for past releases.
>>>>>
>>>>
>> While I agree it should not prevent us from releasing as it is something
>> that we would need to do anyway for instance if we discover a serious
>> corruption bug, it still puts us in an lesser known territory that means
>> that we need to be more careful when testing the release.
>>
>> Most of the work has already been done so I don't think we should cancel
>> this release, we just need to test more carefully, but this is something
>> that would refrain me from proposing to do bugfix releases of previous
>> minor releases again in the future, unless there is a major bug that needs
>> to be adressed.
>>
>


-- 
Anshum Gupta

Mime
View raw message