Recommendations for version numbers in port names

[Lawrence Velázquez]

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

On Sep 16, 2014, at 5:22 PM, Ryan Schmidt <ryandesign at macports.org> 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.

> 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`).

> 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.

> And I don't want to take on massive port renaming efforts for the sake of the formatting of a version number. I don't plan to change the PHP ports and the almost 100 PHP modules and the dozen ports that have PHP variants, and I'll bet nobody wants to take on changing the Python ports and the almost 1000 Python modules and hundreds of ports with Python variants. Remember it would not only be the work of renaming all the ports, but also developing an upgrade strategy to help all the existing users of the ports under their current names.

It would be a lot of work, but it doesn't have to happen all at once, in a short period of time.

Or, again, we could just focus on renaming variants. Consistency of port names is rather less important.

vq