While tinkering around with adding ruby support to efsdeploy, a glaring
mistake has been made obvious.
The compiler names are a simple, flat names space. For the C/C++ compilers
we have names like:
gcc44, gcc45, rhel41, etc.
Where the gcc prefix is used for compiler releases from gnu.org, and the OS
prefix is used for compiler releases from the distribution vendor.
Presumably, we'll eventually have debian44, freebsd45, whatever, in order to
be bug for bug, feature for feature compatible with those compilers.
Until now, the only other compilers have been the perl compilers, and they
use perl major.minor number:
5.10, 5.12, 5.14, etc.
If the same convention is applied to ruby, which based on everything I have
read so far has a horrible backwards compatibility record, then we would use
the major.minor.subminor convention (although in practice, I have heard that
even patch levels are NOT backwards compatible, but that's a different
issue). That would mean using:
1.8.7, 1.9.2, etc.
Now, suppose we continue this convention for python, which is the next
logical compiler to integrate.
2.5, 2.6, 3.0, etc.
See the problem? Eventually, some OTHER language or compiler is going to
overlap version numbers, and then we have a namespace collision. In
hindsight, it would have been better to use one of the following conventions
(the 2nd one being similar to the gcc convention, of course).
pl-5.10, pl-5.12, etc
pl5010, pl5012, etc.
The second convention is deterministic since the perl community has a
versioning scheme that can map one to one to such a string.
I am going to give this some thought while I play with ruby, and then python
support, but I think it makes sense to at use this new convention for the
new interpreted languages. This would suggest using names like:
rb-1.8.7, rb-1.9.2, etc.
rb187, rb192, etc.
py-2.6, py-2.6, py-3.0, etc.
py25, py26, py30
Now, the problem with using the convention with no punctuation is possible
ambiguity in the future. Both 1.9.2 and 1.92 would map to 192, for example.
With perl, the mapping's simple, based on the documented versioning
standard used, but I am not familiar with how ruby and python plan to
versionized future releases.
The most future-proof convention would be to use rb-1.9.2 and py-3.0, which
is the direction I'm leaning. This also means that if we want to migrate
perl to the same convention, it's only a matter of prefixing the strings
with pl-. Given the HUGE amount of existing software we have built for
5.10 and 5.12, I would suggest we make that change when we implement
pl-5.14, and leave the existing 5.10 and 5.12 the way they are. Trying to
retroactively change those conventions would add a LOT of complexity for
nothing more than cosmetic OCD-compliance.
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
