Hi, I think we should definitively switch to llvm-10 for the next release, and just sort out whatever issues that causes. We should not perpetuate the mistake, now its know, and I suspect it won’t actually be that bad to deal with it.
As for back porting that to the current versions, I agree this might require a bit more work to fix all references, but I personally still would probably look into doing it, as I think long term having everything from 5 on onwards using the same scheme would ultimately simplify things. Chris > On 14 Jan 2020, at 6:29 pm, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > We finally had a situation where the llvm-N.0 naming convention did not work > out, and we have a port named llvm-7.0 now actually being llvm-7.1.0. This > inaccuracy generates a "disturbance in the force”. AFAICT, this has not ever > happened before, so we always got away with it. > > We can just live with this, probably, as it is so rare, at least so far. Or > we can rename all the llvm/clang/lldb ports from 5 onwards to llvm-5 instead > of llvm-5.0, etc. This would be more accurate, technically, but otherwise > meaningless in practice. However, there are so many Portfiles, PortGroups, > and base references that I’m rather fearful of the fallout from doing that at > this point in time. > > Whether we do that or not, the new llvm 10 series is going to be out soon. We > can name that llvm-10, and deal with the differences that name might trigger > somehow, if there are any, in the Portfiles, PortGroups, and base — or we can > just call it llvm-10.0, clang-10.0, and lldb-10.0, and suck it up. That would > likely cause less widespread wreckage in the many files that depend on these > names, but might again come up with another slightly misnamed port in the > future, where some future port named llvm-12.0 is actually llvm-12.2.0 or > similar. > > Either way, we either get a (possibly) less accurate portname, or we risk > unexpected wreckage. > > > Open to opinions. > > Ken
