On Jan 14, 2020, at 18:42, Chris Jones wrote:
> On 14 Jan 2020, at 10:39 pm, Ryan Schmidt wrote:
>
>> The gcc and postgresql ports are named correctly, both before and after
>> their version numbering scheme changed. If llvm/clang's version numbering
>> scheme changed, it would be good if the port names agreed with the scheme as
>> well. I agree this has the potential to cause breakage which should be
>> handled carefully.
>
> Its not really that the version number format has changed,
I didn't say the version number format changed, I said "if [the] version
numbering scheme changed". And with a little searching I was able to remind
myself that indeed it did:
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
Though according to that blog post, the "major version" after the change shall
continue to have the second version number component in it, even though it is
zero ("4.0", "5.0", just as previous major versions were "3.8", "3.9"), which
explains why the ports are named the way they currently are. Maybe they changed
the scheme again sometime on or before the 7.1.0 release. I don't know; I can't
find a blog post about that and they failed to publish the 7.1.0 release notes
so I can't check there. The blog post says "the minor component will stay at
zero since no minor releases will be made". Apparently they changed their mind
on that point at least. Or maybe the 7.1.0 release is a one-time anomaly and
they will continue to maintain a zero minor version number component in future
versions.
> One other thing to note, as I comment in
>
> https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493
>
> Is when clang 10 comes out we anyway will have issues with the logic in a few
> places, regardless of if we drop the .0 from the port name, as there is
> hardcoded logic in a few places that will break once we have a major version
> with two digits in it... so seeing as we have to do something regardless, we
> should drop the .0 at the same time, as it probably adds little additional
> work.
Certainly if anybody made assumptions in any code that the first component of a
version number is a single digit, that should be fixed ASAP, especially for
llvm/clang where a two-digit first component is imminent. The whole point of
keeping the period in the version number that is part of the llvm/clang port
name was to avoid the ambiguity that was anticipated to happen once any of the
version number components exceeded a single digit. The discussion surrounding
the decision to adopt that naming scheme for the llvm/clang ports seems to have
escaped the attention of the authors of the compilers-1.0 portgroup in which
clang versions must be specified without the period. Maybe the interface of the
compilers-1.0 portgroup should be changed so that clang versions are specified
with the period.
