On 6/29/16 1:44 AM, Thierry Goubier wrote:
Hi Nicolas,
Le 29/06/2016 10:24, Nicolas Passerini a écrit :
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.
How is the libgit integration going?
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.
Ok.
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.
All the Monticello GUI : track down version numbers to order stuff in
the lists views everywhere.
The Metacello / Gofer stuff (Configurations, Baselines) also use
version numbers.
One of the difficulty of switching will be the cohabitation of
number-based systems (smalltalkhub) and SHA-based systems, especially
when you do things like copying a version from a git repository to a
smalltalkhub repository.
My thoughts are that the we'd change the package name parsers to accept
hex numbers as version numbers ... granted packages with hex version
numbers could wreak havoc if they found their way into an mcz
repository, but frankly a developer choosing to go metadata-less isn't
likely to be using very many mcz repositories anyway and if a project
is migrated to an mcz repository I would think it would be acceptable
for the first version in the ancestry to be the Short SHA (allowing one
to trace an ancestry manually in a git repo if desired) and subsequent
version numbers could use decimal notation ...the version number is not
involved in the maintaining monticello ancestry (using a version number
is a convention as far as monticello is concerned)
That's why I suggested to change the ordering relation to a partial
order based on the property A is an ancestor of B -> B is before A.
Frankly for git packages, I have toyed with notion of eliminating the
version number from the package name altogether. The version number in
the name of a package was invented as a convention because otherwise
there was no way to distinguish different Monticello packages from each
other ... in FileTree we simply use the name of the package to name the
directory and technically there is only ever one version of a package in
a git repo anyway ... perhaps we should look at completely eliminating
the version number from the package altogether?
With the cypress package extension, Metacello should be ignoring the
version number anyway --- a package without a version number is
"obviously metadata-less" ... Hmmm, it might even be easier to parse a
package that doesn't even have a version number (or author name for that
matter) ... If we are going to be making mods to tools it might be
better to go this route ... What do you guys think?
Dale
