You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2014/03/17 17:29:43 UTC

[jira] [Commented] (SOLR-5873) Improve JavaBinCodec's backward compatibility tests

    [ https://issues.apache.org/jira/browse/SOLR-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937985#comment-13937985 ] 

Mark Miller commented on SOLR-5873:
-----------------------------------

Wrong Mark Miller pinged ;) I'm one of the last ones that comes up - markrmiller@gmail.com username rather than hakeber.

> Improve JavaBinCodec's backward compatibility tests
> ---------------------------------------------------
>
>                 Key: SOLR-5873
>                 URL: https://issues.apache.org/jira/browse/SOLR-5873
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Varun Thacker
>
> SOLR-5265 added backward compatibility tests, but it tries to read a pre-written binary file to check if there is a break a not. If we add more types to JavaBinCodec the test will need to be updated too, which will be error prone again.
> This is what [~hakeber] proposed on IRC - 
> - A test that I was thinking of: we could have a jenkins job that ran a script that checked out the previous version of lucene and the the latest
> - Then use the solr/cloud-dev scripts to start a cloud cluster
> - Index some docs
> - Stop a node at a time, replace webapp with the latest in a rolling upgrade fashion
> - Then we have a full rolling upgrade test
> This would be a better approach for back compat tests.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org