I don't think that new spkgs should be required to work on older released versions. For example, two spkgs which I have a strong interest in are eclib (standard) and database_cremona_ellcurve (optional); in both cases, changes to a new version of the spkg require patches to the Sage library in order to work. This seems to be a different issue from the ones discussed at #11616, but relevant to this policy discussion.
In order that sage -i just work in the normal way for users (where the appropriate spkg is obtained magically from the internet) it would surely not be hard to have a separate set of these optional/experimental spkgs stored for each release, so that the versions obtained are exactly the ones current at the time of the release, or bug-fixed but still working with that release. This would keep things simple for users, while developers can obviously run sage -i on any spkg they want. And anyone testing (say) a 5.0 beta could access the latest versions of spkgs using simply sage -i which would get them from the (testing) spks-5.0 directory on the server. If that would work and be agreed, we may still want to have a shelf-life for older releases after which optional spkgs may be deleted from the server to save space. Just a suggestion. John On 13 April 2012 09:43, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > I would like to know whether Sage developers find it important that > *new* spkgs (developed today) work on *older* versions of Sage (say, > sage-4.7 or sage-4.8). > > Personally, I don't care at all about this. If it works on the latest > beta, that's fine. I think we should not make spkg-install files more > bloated by adding extra code to ensure compatibility. > > Leif Leonhardy, on the other hand, thinks it's good to add code to > spkg-install if it makes the spkg work on older Sage versions. > > This is not about upgrading the *whole* Sage (./sage -upgrade), which I > think we should support. This is only about installing just one spkg > (./sage -i ...). > > This disagreement is part of the reason why the review process is stuck > on #11616 (upgrade and fix MPIR, a sage-5.0 blocker). Any opinions? > > > Jeroen. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
