On 6/18/07, Brian Granger <[EMAIL PROTECTED]> wrote:
> I didn't know SAGE was actually using them. Is this when sage -update
> is run? My understanding is that the decision to upgrade something
> was based on the timestamps if the files compared with the stub in the
> installed directory. Am I mistaken.
Yes. It is based on the version number. Timestamps aren't used
for upgrading.
> Is there a standard approach for these version numbers? At times I
> have seen a projects version number upgraded, but the .pn version
> number remain the same. For instance, the python spkg is named:
>
> python-2.5.1.p3.spkg
>
> But I don't think the .p3 means the third version of the spkg for
> python-2.5.1.
The standard is
package_name[dash]official-version[dash]sage_patch_number
Thus python-2.5.1.p3.spkg is the fourth (0-based) version of the
Python 2.5.1 package. If the package number jumped from 2.5.0.p3
to 2.5.1.p3 that would be a mistake.
> This seems a bit confusing to me. Especially because
> some spkgs don't have a .pn version, even though they were updated.
Sometimes a package is updated in a trivial way, e.g., something is
added to the README or a directory is reorganized, but there is absolutely
no reason to force very SAGE user out there to upgrade/build that package.
In such cases, I usually do not update the version number.
> I
> don't mind having a version that denotes the spkg version, I just want
> to make sure that those version number are consistent and standardized
> and have a purpose that is not redundant. Could we use md5 sums for
> this? In many cases, I do this anyway, because the .pn version number
> is not a reliable way of determining if an spkg has changed.
The md5 sums are unfortunately not in order, so that doesn't work.
md5 only tells you whether two packages are different, not which is
newer.
> > One issue is that it isn't a readme, actually. It's a description of how
> > the package was made.
>
> True, then maybe SPKG.txt makes more sense? Or maybe BUILD-NOTES.txt?
> SPKG-BUILD-NOTES.txt?
SPKG.txt is I think clearly the best choice given our constraints.
William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
