looks like 7.1.0 is a very unusual, unlikely to be repeated soon, event. http://llvm.1065342.n5.nabble.com/LLVM-7-1-0-Release-td128369.html
Ken > On Jan 16, 2020, at 07:56, Ryan Schmidt <ryandes...@macports.org> wrote: > > > >> 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. >
