Nicolas,
Over the long July 4th weekend, I realized that the package-cache needs
to be considered in the package naming scheme ...
As currently implemented, the GitFileTree scheme of sequentially
numbering version numbers based on the order of git commits is
problematic when the package-cache is considered, since switching
branches can lead to a package named XXX-dkh.12 being in the
package-cache and there is no way to know whether it is the "right
package" ...
The short sha scheme would guarantee that the package-cache would not
have improper collisions, so this is an argument in favor of going that
route ...
When reading a package from a metadataless repository using FileTree as
opposed to GitFileTree, the package-cache is even more problematic since
all packages are given the same author-version number: cypress-1 and you
are virtually guaranteed to have package-cache problems
The scheme that I favor: eliminating both author and version number from
the name, suffers from the same package-cache problem ...
Now I believe that I should be able to "solve the package-cache problem"
in Metacello when using the Cypress extension, because Metacello is
already aware of the package-cache when doing a fetch ...
Unfortunately loads from the Monticello Browser and Gofer will still be
using the package-cache unless those tools are made aware of
metadataless repositories or the decisions about whether or not the
package-cache is used is delegated to the repository instance itself ---
probably the preferred solution --- and an approach that I also consider
as I work through the issues for Metacello ...
Anyway, the short-sha may actually be the best solution. I have found
the short sha very useful when displaying the loaded version of a
project in the project browser for tODE and echoing the short sha (sans
author) in the package names, would provide a useful reminder of the
version that was checked out when the package was loaded ...
Dale
On 06/29/2016 01:24 AM, Nicolas Passerini wrote:
Hi Dale, Therry, I am working on a libgit-based git integration for
Pharo and I am facing the same problem about version numbers. So maybe
I can help you if you are working on that.
I had the same idea as Dale, using short SHAs instead of correlative
numbers, but I didn't have the time yet to got down that path.
Therry, you said that
you'll have a bunch of stuff expecting version numbers that will
stop working.
Do you already know which stuff will stop working? That would be realy
helpful.
