Recommendations for version numbers in port names

[Mihai Moldovan]

On 01.10.2014 09:39 pm, Sean Farley wrote:
> Lawrence Velázquez writes:
>
>> 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.
> This is an important point, thanks.

Variant names, however, are easily changed with help of TCL magic. This is not
as easy for whole ports.
(Ex.: keeping the old variant around, which "only" activates the new variant if
it itself is activated, to ensure a smooth upgrade path. Much like the no_foo =>
foo variant changes.)


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

port install (and other subroutines) already recognize "gsed-bar+foo-baz" as one
port name, so the problem is (currently) not a problem anymore.

IIRC current base requires variants to be delimited by a white space from the
port name.  A version number is already delimited by "@" (with or without white
space after port name, so "@" is indeed an invalid port name character), with
variants following the version number (which naturally may contain dots, but not
'-' or '+'?)

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

This issue could be fixed by requiring white spaces after/before each individual
variant. But we probably don't want to go there.


>>> The only disadvantage I see to the old naming scheme is ambiguity [...]
>> I haven't done any tests, but I'd much prefer adding the periods, if possible.
> I agree with this, too.

Yes. Ambiguity should be avoided at all costs.


Mihai