Recommendations for version numbers in port names

Sean Farley sean at
Wed Oct 1 12:39:22 PDT 2014

Lawrence Velázquez writes:

> Resurrecting this thread. Let's keep general renaming discussion here.

Sure, sounds good.

> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt <ryandesign at> wrote:
>> It's been proposed on this list that we should rename MySQL ports e.g. mysql51 -> mysql-5.1; this would be to match the existing new ports mariadb-10.0 and mariadb-10.1. Consistency is good, especially within a particular type of software (e.g. MySQL in this case) but renaming MySQL ports is more problematic than renaming most ports, because MySQL ports are database servers and users may have databases and config files in their default version-specific directories which the user would manually have to move.
> Consistency is good, but I'd argue not especially critical. If migrating a particular port or set of ports would be too much work, it would not be the end of the world if we left it/them.
> Consistency of variant names is probably more important than consistency of port names, since it affects variant inheritance.

This is an important point, thanks.

>> The problem with dashes in port names is that a dash is not a legal character in a variant name because it is confused with the syntax for disabling a variant, and often when there are multiple versions of a port, other ports will want to reference those multiple versions in corresponding variants.
> True, but we already have tons of ports with hyphens in their names. It seems odd to me to use hyphens in some places (e.g., `py34-requests`) but avoid them in others (`gcc49`).

Very much agreed.

>> The problem with dots in port names is that so far "port lint" has declared the dot an illegal character in a variant name. This has led the perl5 port for example to adopt variant names like perl5_16 which I've always found a little confusing. It has been nice that under the original naming scheme, one could assume that in many cases the variant name matches the name of the dependency that will be added. If you want to use the python27 port, you use a port's +python27 variant, etc.
> Matching variants and dependencies is certainly nice, but I don't think we should get hung up on it, since the dependencies are added automatically. I personally would be entirely fine with `+gcc4.9` pulling in `gcc-4.9`, and I think the hyphenated port names look cleaner. This is entirely subjective, of course.
>> The only disadvantage I see to the old naming scheme is ambiguity when a version number component reaches two digits, e.g. is the scala210 port version 2.1.0 or 2.10? (It's 2.10.) Is the ruby186 port version 1.8.6 or 1.86? (It's 1.8.6 -- perhaps this port should have been named ruby18 instead.) Leaving the dot in would remove the ambiguity, as demonstrated by the Perl ports, and "port lint" may be overly cautious in its prohibition of the dot in variant names. Someone should do some tests. Make variants with dots, like "mysql5.1", and see if they work correctly. Can you install the port? Can you upgrade the port? Can you uninstall the port? What if other variants are also selected? If everything works fine we can relax this lint restriction.
> I haven't done any tests, but I'd much prefer adding the periods, if possible.

I agree with this, too.

More information about the macports-dev mailing list