
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi,</div><div dir="ltr"><br><blockquote type="cite">On 14 Jan 2020, at 10:39 pm, Ryan Schmidt <ryandesign@macports.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><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></div></blockquote><br><div>Its not really that the version number format has changed, more different emphasis is placed on the major and minor versions. Like with gcc, clang has effectively decided to make more regular (yearly) major version updates for a while now, and for the minor and patch sub versions to mean just that, ‘minor’ changes. Given this, its now more natural for macports to just label its clang ports, as with gcc, by only the major version, and not as before major.minor.</div><div><br></div><div>One other thing to note, as I comment in </div><div><br></div><div><a href="https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493">https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493</a></div><div><br></div><div>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.</div><div><br></div><div>Chris</div></body></html>