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