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 wrote:
>
>
>
>> On Jan 14, 2020, at 18:42, Chris Jones wrote:
>>
>>> On 14 Jan 2020, at 10:39 pm, Ryan
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
Hi,
> 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
>
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
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
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
