Thats still only addressing that objects can be unpickled; You'd also have 
to run the entire testsuite with the unpickled objets if you want to have 
any reasonable guarantee that they are actually working. Put differently, 
how likely do you think it is that some old pickle unpickles and passes 
superficial tests, but gives a mathematically incorrect answer if you call 
some specialized method? 



On Sunday, October 29, 2017 at 8:22:39 PM UTC+1, Simon King wrote:
>
> On 2017-10-29, David Roe <roed...@gmail.com <javascript:>> wrote: 
> > I agree that removing pickles from 6+ years ago is a good idea. 
> > 
> > I do think, however, that the idea of being able to save objects between 
> > versions of Sage is valuable.  And we need some way to test it.  Maybe 
> we 
> > could move to some sort of rolling pickle jar, where we allow 
> deprecations 
> > after a certain amount of time? 
>
> Does the following make sense? 
>
> Some patchbot could be used to build (one after the other) 
> old-but-not-too old versions of SageMath. In SageMath version 
> x-y-z, the original pickle jar is opened and then saved in 
> version x-y-z. So, we would create *several* (say, n) versions 
> of the pickle jar, and in the best case each Sage version 
> would be available on m machines with different architecture. 
>
> The above has to be done *once*, resulting in m*n pickle jar 
> versions. 
>
> As part of the release process of a new version of SageMath, 
> a new version of the pickle jar is created by some patchbots 
> on m different machines and replaces the m oldest versions of 
> the pickle jar. 
>
> Thus, one has a rolling pickle jar in m*n versions. 
>
> The m*n-fold pickle jar should not pollute the SageMath sources. 
> In that way, a new pickle jar version wouldn't result in a new 
> to-be-merged git commit. Instead, the jar should only be stored 
> on some SageMath servers. 
>
> It should be tested by our test bots (i.e. the machines 
> connected to trac tickets) whether all m*n versions of the pickle 
> jar unpickle, *and* whether all m*n versions of the same unpickled 
> object actually evaluate equal. It would just (to some extent) 
> test both machine independence and backwards compatibility. 
>
> However, that test would *not* remain part of the test suite that 
> is executed by a user doing "sage -t". It is a test for test 
> bots only. 
>
> Best regards, 
> Simon 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to