Robert Bradshaw wrote:
On Mar 19, 2010, at 4:07 PM, Jaap Spies wrote:
Dr. David Kirkby wrote:
However, there is still a significant number of .spkg updates each
release.
Yes. I would like a policy that spkgs are only updated on x.y releases,
but I'm in the minority with you in trying to get release numbers to
mean something more concrete.
Robert, I doubt we are in such a minority. We might have been the only two
people to say this, and my efforts to persuade William of this have been
unsuccessful, but I have no evidence to suggest that our views are a minority view.
Most major pieces of software use the system we propose - both commercial like
Mathematica and Open-source like gcc. Since most software uses the system we
propose, it suggests to me most developers think it is a good idea.
I don't know if it is possible in trac to have the release number of the next
release as 'next release' then at some point during the release cycle, agree on
a version number, taking into account what changes have occurred.
Whoever introduced this package or/and the one who gave it a positive
review
should have tested this change on all supported platforms :)!?
Or at least a reasonable selection.
Testing on every linux distribution would be an enormous task. Testing on all
supported OS X versions would probably be too. Since there is only one supported
(or will be supported in Sage 5) version of Solaris, testing on that is less of
a hassle.
I think testing on at least one supported Linux system, at least one supported
OS X system and at least one supported Solaris system would be a reasonable
minimum.
My thoughts as well. Part of this may be due to the fact that currently
spkgs don't fit as well into the whole trac/mercurial queues refereeing
paradigm.
Perhaps, though I think the main issue is that there are a lot of code changes,
and in most cases the person updating the .spkg did write the code, so they
don't know in much detail what changes have taken place.
Hence my point number #9 in the thread "Guidelines for updating standard
packages".
- Robert
Dave
--
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 unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.
