renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

[Chris Jones]

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.webuse at 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