
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>looks like 7.1.0 is a very unusual, unlikely to be repeated soon, event.</div><div><br></div><div><a href="http://llvm.1065342.n5.nabble.com/LLVM-7-1-0-Release-td128369.html">http://llvm.1065342.n5.nabble.com/LLVM-7-1-0-Release-td128369.html</a></div><div><br></div><div>Ken</div><div><br>On Jan 16, 2020, at 07:56, Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><span></span><br><span>On Jan 14, 2020, at 18:42, Chris Jones wrote:</span><br><span></span><br><blockquote type="cite"><span>On 14 Jan 2020, at 10:39 pm, Ryan Schmidt wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>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.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Its not really that the version number format has changed,</span><br></blockquote><span></span><br><span>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:</span><br><span></span><br><span><a href="http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html">http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html</a></span><br><span></span><br><span>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.</span><br><span></span><br><span></span><br><blockquote type="cite"><span>One other thing to note, as I comment in </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><a href="https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493">https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>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.</span><br><span></span><br></div></blockquote></body></html>