Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?
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 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 well. I agree this has the potential to cause breakage which should be
>>> handled carefully.
>>
>> Its not really that the version number format has changed,
>
> 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:
>
> http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
>
> 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.
>
>
>> One other thing to note, as I comment in
>>
>> https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493
>>
>> 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.
>
> 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.
>
Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?
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 the port names agreed with the scheme as
>> well. I agree this has the potential to cause breakage which should be
>> handled carefully.
>
> Its not really that the version number format has changed,
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:
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
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.
> One other thing to note, as I comment in
>
> https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493
>
> 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.
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.
Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?
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 > well. I agree this has the potential to cause breakage which should be > handled carefully. 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. One other thing to note, as I comment in https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493 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. Chris
Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?
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.
Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?
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 > 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
renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?
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
